The tile layout has been refactored to display a list of recent cases
instead of the currently active case. This change includes:
- Removing the "current case" view and its associated logic.
- Implementing a new `caseListContent` function to render a list of up
to 8 recent cases.
- Modifying the main `buildTileLayout` to integrate the new case list
and a prominent "Neu" (New) button.
- Updating the styling and click handling to reflect the new layout and
functionality.
Use the current case's oneliner text as the title for the remote input
intent. This ensures consistency with the CaseListScreen's display when
no oneliner is present, showing a "…" placeholder. This improves the
user experience by making the system input picker's title match what the
user just selected.
Increase `max_completion_tokens` for `gpt_oss_120b` from 8192 to 16384
to prevent incomplete responses.
Navigate to the detail screen before the recording screen when starting
a new case, ensuring correct back navigation.
When a previous analysis attempt fails and leaves a failure marker, the
retry mechanism now correctly identifies this state. It removes the
stale
input file, allowing the retry to proceed without a conflict error. This
ensures users can recover from analysis failures more gracefully.
An empty `backend` form field now correctly falls back to the default. A
non-empty field submitted by a non-admin user is rejected with a 403
error, preventing potential tampering or issues arising from stale
sessions after role changes.
This commit adjusts the configuration for the `gpt-oss-120b` model to
run in plain-text mode. This is necessary because when
`reasoning_effort` is set to "medium", the reasoning tokens combined
with schema-constrained decoding can exhaust the `max_completion_tokens`
budget, leading to an empty content response.
The change restores the previous behavior where `gpt-oss-120b` was
configured without `response_format` or `top_p`, ensuring the request
body sent to Ionos remains byte-identical to the pre-multi-backend
state. This prevents regressions and maintains stability for existing
production workflows.
Configure Llama 3.1 405B with specific temperature, top_p, and a format
instruction. This addresses issues with infinite repetition and empty
document generation observed with this model. The format instruction is
added as a separate system message to avoid modifying the core medical
prompt.
`recovery::enqueue_pending_for_user` previously enqueued any case with
`analysis_input.json` and no `document.md`, ignoring the failure marker
that `auto_trigger::evaluate_case` already honours. A timed-out LLM
call (e.g. Llama 3.1 405B at ~20 tok/s with default 4096 max_tokens)
left the input in place, the next case-list reload re-enqueued it, and
the worker hung another full timeout window — starving fresh user
clicks behind a failed retry loop.
Recovery now mirrors the same skip: if a marker exists whose
`last_recording_mtime` matches the input's, treat it as "already
tried, do not retry until input changes". Fresh recordings bump the
mtime and recovery picks the case back up.
Replace the single [llm] block in settings.toml with a curated catalog
of LLM "backends" (provider + model + sampling params + system prompt)
in server/src/analyze/backend.rs. Two backends ship initially:
gpt_oss_120b (default, reasoning_effort=medium) and llama_3_1_405b
(uses response_format: json_schema to sidestep the <|eot_id|> leak).
The case page now renders one submit button per available backend; the
clicked button's name=backend value rides through AnalysisInput.backend_id
to the worker, which looks it up via find_backend() with default fallback.
A submitted unknown backend id is rejected as 400. .analysis_failed.json
records the failed backend and the failure banner surfaces its label.
The API key now comes from IONOS_API_KEY (env), not settings.toml; the
[llm] section is read into a discarded field so old configs still load.
Backends without a satisfied requires_api_key are filtered from the UI
(any_backend_available()). Three end-to-end tests that mocked the LLM
endpoint via settings.llm.url are #[ignore]'d with a clear note — they
need per-test backend injection (Arc<Vec<LlmBackend>> through the worker)
before they can be re-enabled.
When an LLM analysis fails, a `.analysis_failed.json` marker is created.
If no document exists yet and the auto-trigger is blocked by this
marker,
the case page must display a banner. This banner provides the failure
reason and a button to retry the analysis, ensuring users are not left
in a dead-end state.
The `read_failure_marker` function is made public to allow the web layer
to access this failure information. The `CasePageTemplate` is updated to
include `analysis_failed` data, which conditionally renders the new
`.failure-banner` HTML.
This change prevents cases from becoming unrecoverable due to transient
LLM errors.
Includes a button for administrators to copy all transcripts and the
document markdown to the clipboard.
The data is embedded as JSON in a script tag and pre-sanitized to
prevent
`</script>` tag injection.
The JavaScript handles copying to the clipboard using the modern
Clipboard API,
with a fallback for older browsers.
Mirrors scripts/.gitignore from feature/mesh-vocab-pipeline so the
regenerable pipeline outputs under scripts/data/processed/ stop
showing up as untracked on main. Identical content avoids a merge
conflict when the feature branch lands.
The `client-desktop` crate is now located within the `clients/desktop/`
directory and renamed to `doctate-desktop`. This change improves
organization and clarity within the project structure.
Replace stale references in 17 Kotlin files:
- doctate-client-core::* -> doctate-desktop::*
- doctate-client-core/src/* -> clients/desktop/src/*
- doctate-common/src/* -> common/src/*
The doctate-common:: crate path stays valid (crate name unchanged).
PendingStoreTest.kt is in src/test/, so the test mirror is also
updated.
Verification:
- grep for "doctate-client-core" / "doctate-common/src/" in
clients/wearos/ returns 0 hits.
- gradlew :app:testDebugUnitTest BUILD SUCCESSFUL (23s) -- also
retroactively confirms stage-2's directory move did not break
any Gradle relative-path assumptions.
- cargo clippy --all-targets -- -D warnings clean in both
server/ and clients/desktop/ workspaces.
This concludes the four-stage server-vs-clients build-world split:
- stage 1 (39cc666): dissolve doctate-client-core
- stage 2 (0c66fc6): rename to common/, clients/desktop, clients/wearos
- stage 3 (7b4fe87): split into standalone workspaces
- stage 4 (this): update wearos anchors
docs/projektplan.md to be updated separately.
Add [workspace] / [workspace.package] / [workspace.dependencies]
blocks to server/Cargo.toml and clients/desktop/Cargo.toml so each
becomes a self-contained workspace with its own Cargo.lock.
Remove the root Cargo.toml and Cargo.lock; the repo now hosts
three independent build worlds: server, clients/desktop, experiments.
Convert common/Cargo.toml to concrete versions (was workspace-
inherited from the root). common/ is consumed via path-dep from
all three worlds, but is not itself a workspace -- consumers
unify versions via their own lockfiles. Add common/Cargo.lock to
.gitignore per Cargo lib-only-crate convention.
Verification:
- server/Cargo.lock has 0 eframe/egui/winit entries
- cargo build --release --locked passes in server/
- test split: server 385 + desktop 89 + common 34 = 508 total
- bin output: clients/desktop/target/debug/doctate (named "doctate")
Move three directories into their target topology:
- doctate-common/ -> common/
- client-desktop/ -> clients/desktop/
- watch/wearos/ -> clients/wearos/
Update doctate-common path-dependency in 3 Cargo.toml files
(server, clients/desktop, experiments) and the workspace
members list in the root Cargo.toml. Crate names unchanged
(doctate-server, doctate-common, doctate-desktop).
Workspace still in single-Cargo.lock form; isolation into
standalone workspaces follows in stage 3. All 508 tests pass,
experiments standalone-workspace also resolves the new path.
Move the 9 client-core modules (case_store, case_update, config,
footer_status, pending_cleanup, server_sync, snapshot_cache,
startup, upload) into client-desktop/src/. Resolve the config.rs
name collision by keeping the TOML schema in config.rs (was core)
and renaming the platform-path wrapper to config_path.rs.
Introduce client-desktop/src/lib.rs so the modules are reachable
under the doctate-desktop:: crate path -- needed for Wear-OS doc
anchors that mirror Rust symbols. Bin target stays as `doctate`
via [[bin]] name in Cargo.toml.
This is the first of four stages preparing the server-vs-clients
build-world split. Workspace still has 3 members; directory layout
unchanged. All 508 workspace tests pass.
Introduce a new field `reasoning_effort` to the `ChatRequest` struct.
This field, set to "medium" by default, allows tuning LLM reasoning
depth to balance hallucination risk against latency and token cost. This
setting is specifically for Ionos' GPT-OSS reasoning models and is
ignored by other OpenAI-compatible models.
The system prompt for the medical assistant has been refactored to
improve clarity and precision. Key changes include:
- Enhanced instructions on handling transcribed errors, emphasizing
verbatim transcription and the use of `==...==` for uncertain parts.
- More explicit guidance on the formatting of dosage schemes, including
the conversion of numerical representations to hyphenated formats
(e.g., "1-0-2").
- Introduction of specific examples for common medical abbreviations and
terms, such as "CDAI > 450", "per os", and "iv.".
- A new critical rule to enclose any output not part of the transcript
in `[...]`.
- The addition of "Ileus" to `medical_terms.txt` and "Adalimumab",
"Infliximab" to `vocabulary.txt`.
The `Gazetteer` struct has been refactored to store `Entry` structs,
where each entry contains a canonical form and a set of bypass aliases.
This change enables the bypassing of Hunspell's dictionary veto for
specific, explicitly defined aliases.
The `parse_line` function has been introduced to handle the new line
format, which allows for `-`-prefixed aliases. Malformed lines with
secondary tokens not prefixed by `-` now result in a hard error, failing
server startup with `io::ErrorKind::InvalidData`.
The `replace` method has been updated to check bypass aliases before
consulting the dictionary, ensuring that explicitly allowed aliases are
used for rewriting. This addresses issues where Hunspell incorrectly
identifies compounds, blocking necessary corrections.
The `README.md` in the `vocab` directory has been updated to document
the new bypass-alias functionality.
This commit removes the `whisper_variant` and `whisper_hotwords_variant`
fields from the `run_id` generation and the `print_meta_summary`
function.
These variants are no longer used as the project is shifting focus to
LLM-based generation. The `run_full_case.rs` example has also been
updated to reflect this change.
This commit introduces the `doctate-canary` service and associated sweep
experiments.
The service provides access to the `nvidia/canary-1b-v2` ASR model via a
native FastAPI API. It includes deployment scripts, Docker
configurations, and detailed documentation on installation, API usage,
and environment variables.
The sweep experiments aim to thoroughly evaluate the Canary model's
performance under various configurations. This includes testing
different inference pipelines (single-shot vs. buffered), decoding
strategies (greedy vs. beam search), and parameter tuning (chunk length,
overlap, batch size, precision). The goal is to reproduce previous
findings and identify optimal settings.
The commit also includes:
- Utility scripts for audio transcoding and manipulation.
- Comprehensive logging and result collection mechanisms for the sweep
runs.
- Detailed analysis of `dur=0` occurrences and word confidence,
concluding they are not reliable indicators of hallucination.
- Documentation on the interaction between decoding parameters,
especially `return_hypotheses`, and the availability of confidence
scores.
Pre-pulling the base Docker image in the deploy script prevents
potential TLS certificate errors during the `docker build` process. This
ensures a smoother deployment by leveraging the cached image layer.
This commit introduces a new standalone FastAPI service for the NVIDIA
Canary ASR model.
Key changes include:
- A new `canary/` directory containing the service code.
- `Dockerfile`: Defines the Docker image for the Canary service.
- `docker-compose.yml`: Configures the Docker Compose setup for running
the service.
- `main.py`: Implements the FastAPI application, model loading, and
inference logic.
- `requirements.txt`: Lists the Python dependencies for the service.
- `CHUNKING.md`: Documents the long-form audio handling strategy for
Canary.
- `README.md`: Provides an overview of the service, API, and deployment
instructions.
- `deploy.sh`: A script for deploying the service to a remote host.
This service allows for independent evaluation and deployment of the
Canary ASR model, separate from the existing `doctate-whisper` service.
It utilizes a buffered inference approach for handling long audio files,
as detailed in `CHUNKING.md`.
The previous run_llm_only only applied the gazetteer post-LLM, which
silently underestimated the production pipeline: tokens like Inoxaparin
or Klappenvizien are caught pre-LLM in production, but the test tool
left them in the LLM input. Adding `gazetteer.replace()` to each
recording before render_prompt mirrors transcribe/worker.rs:138 exactly,
making sandbox results faithful to production behavior.
New prompt variants kept for the iteration record:
- v3_treue_konsolidiert.txt — the winning variant now in
server/src/analyze/prompt.rs; redundancies eliminated where they were
not load-bearing
- v4_treue_kompakt.txt — rejected variant (3/3 unmarked Hypotonie
hallucinations); kept so future iterations don't repeat the
experiment
baseline.txt now mirrors the current server prompt (was a stale
pre-v2 snapshot), so future sandbox runs against `baseline.txt`
compare against what is actually shipping.
Sandbox-validated against case c414cf52 (3 runs each, fair pre+post-LLM
gazetteer pipeline): the new prompt eliminates two hallucination classes
the prior version produced — unmarked "Hypotonie" when the dictation said
"Hypertonie" (0/3 vs 2/3) and inventing units like "35 ng/l" for values
without unit (0/3 vs 2/3) — while keeping Latin terms (Punctum Maximum
etc.) intact in 3/3 runs vs 2/3.
Block layout reorganized so each rule appears exactly once: AUFGABE /
QUELLE / KORREKTUR-POLITIK / TREUE / CHRONOLOGIE / DOSIERUNGSSCHEMA /
MARKIERUNGEN. The removed "AKTIVE KORREKTUR (nicht durchreichen)" hammer
block is no longer load-bearing because the gazetteer's pre-LLM pass now
catches the typical drug-name typos before the LLM sees them.
Vocabulary additions (single-token, alphabetical, ≥5 chars):
- vocabulary.txt: Enoxaparin (was missing — Inoxaparin→Enoxaparin is a
recurrent ASR error and the prior pipeline relied on the LLM alone)
- medical_terms.txt (new file, picked up by the dir-glob loader):
Holosystolikum, Klappenvitien, Koronarbaum, Pumpfunktion
Datei enthielt Bisoprolol/Ramipril mit den exakten Schemata aus dem
Test-Case c414cf52 — klassisches Curve-Fitting, das beim Test gegen
genau diesen Fall keinen Erkenntnisgewinn bringt und beim Roll-out
auf andere Fälle aktiv halluziniert (Whisper bias'd auf gelistete
Termini, auch bei Stille oder Gemurmel).
Whisper-Initial-Prompts werden vorerst nicht weiter iteriert: Das
Hauptproblem 1-0-0/1-0-1 ist durch den LLM-DOSIERUNGSSCHEMA-Block
bereits gelöst, und der Halluzinations-Risikoaufschlag bei Whisper-
Prompts ist höher als bei der LLM-Stufe. baseline.txt (leer) bleibt
als Slot-Referenz erhalten.
Sandbox-iteration unter experiments/case_c414cf52 (3 Runs je Variante,
gpt-oss-120b @ Ionos, temperature=0). v2_treue gewinnt gegen Baseline
und v1_treue auf folgenden Achsen ohne Curve-Fitting im Prompt:
- Active drug-name correction (Inoxaparin→Enoxaparin, Thorazemit→
Torasemid, AFREF→HFrEF) durchgesetzt: 3/3 statt 0/3
- Schema 1-0-0 / 1-0-1 zuverlässiger: 3/3 statt 2/3
- Troponin-T fehlende Einheit als ==35== markiert (vorher unkommuniziert)
- Hypo/Hyper-Verlaufsgeschichte aus widersprüchlichen Aufnahmen
unterdrückt: 0/3 (war 1/3 in v1_treue)
- Anatomische Lokalisationen, "adipöser Ernährungszustand" und
Diktat-Reihenfolge bleiben treu (vorher selten aber gelegentlich
weggelassen oder umsortiert)
- Format als Fließtext explizit, Pseudo-Headings reduziert
Strukturell offen (kein Prompt-Fix möglich): "Holosystolikum" aus
Whispers Halbwortruine "Tolikum", "Koronarbund"-Halluzination aus
"Corona-Baum" — beides braucht Gazetteer-Erweiterung oder
Tokenizer-Refactor, separate PRs.
Umstellung auf Rust-Raw-String macht die Prompt-Datei deutlich
lesbarer (keine \n-Escapes, keine \"-Escapes mehr).
Nested Cargo-Workspace unter experiments/ als Pfad-Dependency auf
../server. Reproduziert die Production-Pipeline 1:1 durch direkte
Wiederverwendung der Server-Module (transcribe::whisper, analyze::llm,
gazetteer, ffmpeg-Remux) — kein eigenes HTTP-Re-Implementieren, kein
Drift-Risiko zur Live-Pipeline.
Drei bin-Targets:
- run_full_case: volle Pipeline (ffmpeg → whisper → pre-gazetteer → llm
→ post-gazetteer), n Runs einer Variante
- run_llm_only: schneller LLM-Iterations-Pfad auf existierenden,
gazetteer-bereinigten Transkripten — spart Whisper-Calls
- diff_runs: qualitativer Vergleich zwischen zwei Run-Verzeichnissen
Repo-Hygiene: case_*/ (Patientendaten, Symlinks zu tmpdata) und _data/
(Run-Outputs) sind komplett gitignored. Nur Code und fall-übergreifende
Prompt-Hypothesen (prompts/) werden versioniert.
Erste Prompt-Varianten zur Treue-Klausel und Konflikt-Auflösung:
prompts/llm/v1_treue.txt, v2_treue.txt.
The `RecordingView` struct now includes `gain_db` to represent
replay-gain. This value is read from the recording's metadata (`.json`
sidecar) and passed to the frontend.
The JavaScript in `case_recordings.html` uses this `data-gain-db`
attribute to apply replay-gain using the Web Audio API. This ensures
consistent playback loudness across different recordings. The
implementation uses a shared `AudioContext` to manage resources
efficiently and handles cases where the browser might not support
`AudioContext`.
Additionally, the audio recording on Wear OS now uses
`MediaRecorder.AudioSource.VOICE_RECOGNITION` instead of `MIC`. This
leverages platform noise and echo cancellation, aiming for a cleaner
signal before server-side gain adjustment.
This commit extracts the logic for mapping audio analysis results into
the `RecordingMeta` fields into a new, pure function
`analysis_to_meta_fields`. This improves testability by separating the
core mapping logic from logging and other side effects.
The previous implementation directly handled logging and conditional
logic within the `run` function. The new function encapsulates these
mapping rules, including handling finite values, silent audio, and error
propagation. The caller, `run`, is now responsible for logging any
analysis failures before calling the helper. Unit tests have been added
to verify the behavior of `analysis_to_meta_fields` in various
scenarios.
This commit introduces the `Loudness` struct to store replay-gain data
(mean, max, and calculated gain in dB) derived from `ffmpeg`'s
`volumedetect`.
The `RecordingMeta` struct is updated to include an optional `loudness`
field. This allows for consistent playback volume across recordings with
varying microphone levels by applying gain in the browser.
Additionally, new `server/src/loudness.rs` and
`server/src/transcribe/ffmpeg.rs` modules are added. The former defines
constants for replay-gain targets and logic to compute gain, while the
latter handles audio analysis using `ffmpeg` to extract loudness
metrics.
The `#[serde(default)]` attribute on the `loudness` field in
`RecordingMeta` ensures backward compatibility with older metadata files
that do not contain this field. Tests are included to verify round-trip
serialization and parsing of older formats.
Introduces a new `validate` module to centralize input validation for
web
requests. This module contains functions to check the shape and format
of
various user-supplied strings before they are processed by the main
application logic.
Specifically, this commit adds validation for:
- Login slugs: Ensures slugs conform to a strict pattern (lowercase
alphanumerics, `_`, `-`) to prevent path traversal and other attacks.
- Magic link tokens: Validates token length and character set to ensure
they are URL-safe and within expected bounds.
- Recorded at timestamps: Enforces a strict RFC3339 format with second
granularity (`YYYY-MM-DDTHH:MM:SSZ`) to prevent filename parsing
issues
and ensure consistent data grouping.
These validators are integrated into the `handle_login_submit`,
`handle_consume` (magic link), and `handle_upload` routes. This change
enhances security by preventing malformed inputs from reaching sensitive
parts of the application and improves robustness by catching data format
errors early.
Unit and integration tests have been added to verify the functionality
of
these validators and their integration into the respective endpoints.
Introduces `PendingStore.nowRfc3339()` to consistently generate RFC3339
timestamps with second granularity. This avoids potential issues with
sub-second precision in filenames and aligns with common timestamp
formatting practices. The helper function is used in `CaseDetailScreen`
and `RecordingViewModel` to replace direct calls to
`Instant.now().toString()`. A new unit test verifies the expected
behavior of the helper function.
This commit changes the way transcriptions are stored and accessed.
Instead of using plain text files (`.transcript.txt`), transcriptions
will now be part of a JSON metadata file (`<stem>.json`). This allows
for richer metadata to be stored alongside the transcript, such as
duration, and provides a more robust mechanism for tracking
transcription states.
The changes include:
- Updating documentation and code to reflect the new `.json` file
extension.
- Modifying file handling logic to read and write JSON metadata.
- Adjusting tests to accommodate the new file format.
Replaces the `.transcript.txt` sidecar with a structured `.json` file
for recording metadata. This change consolidates transcript text,
duration, and other potential metadata into a single, extensible JSON
object.
This also refactors the `TranscriptState` enum to better represent the
on-disk state (absence of file means pending) and the in-memory
representation. The `Transcript` enum now specifically models the
terminal outcomes of the transcriber (`Silent` or `Content`).
The commit includes updates to documentation, data structures, path
handling, and various tests to align with the new metadata format.
Config sheds its 14 Bucket-B fields (retention, whisper, ollama, llm) and
gains a sibling Arc<Settings> in AppState, loaded from settings.toml at
startup via Settings::load_or_default. Workers (transcribe, analyze,
recovery, auto_trigger) and routes (health, bulk, case_actions,
user_web) take settings as a separate parameter or State<> extractor;
Config::llm_configured moves to Settings::llm_configured.
TestConfig::build_pair() returns (Arc<Config>, Arc<Settings>); the new
create_router_with_settings / create_router_and_session_store_with_settings
helpers wire both into integration tests that exercise LLM/Whisper/Ollama.
The legacy single-Arc create_router falls back to Settings::default()
so the 17 non-LLM tests stay untouched.
Verified: cargo build clean, clippy --all-targets clean, 318 tests pass.
.env shrinks to bootstrap values only (port, paths, log, auth, deploy
flags). The 14 admin-tunable values (retention, whisper, ollama, llm)
move to a new settings.toml with serde(default)-based per-section
defaults and an empty-prompt fallback to the code default. settings.toml
is gitignored alongside .env; settings.toml.example is the template.
This commit fixes the file layout. The server-side wiring (Config shrink,
AppState integration, consumer migration) follows separately.
Tap-to-edit on the case detail now does both halves:
1. Optimistic local update (caseStore.setOnelinerLocal) — UI flips to
Manual immediately, no waiting for the network round-trip.
2. PUT /api/cases/{case_id}/oneliner with X-API-Key — fire-and-forget
so an offline edit doesn't block the UI. On HTTP failure we log;
the local Manual sticks and the next manual edit (presumably online)
gets pushed up. Edits before the case has been uploaded server-side
will 404 here — accepted divergence.
OnelinerOverrideClient mirrors the server contract from
server/src/routes/oneliner_override.rs:108-124 exactly: PUT body is
{text: string}, response is OnelinerState (Manual variant). 5 new
MockWebServer tests cover happy path, 400/404/network classification,
and the on-the-wire request shape.
UI: 👤 prefix on doctor-authored OneLiners across all three surfaces
(CaseListScreen row, CaseDetailScreen large text, Tile center). Auto-
generated (Ready) and unset (Empty/Error/null) states render without
the prefix, so the doctor can tell at a glance whether they wrote
this themselves. Verified live on emulator-5556 against existing
server Manual cases ('Kastanienbaum', 'eigener Bezeichner').
78 tests green total.
Without this, the watch would only run a poll cycle if the pending
queue happened to be non-empty — meaning the case list was empty
forever for users who didn't dictate before opening the app. Kicking
on every launch makes the foreground service start, primes the case
store from the snapshot cache, then polls /api/oneliners.
Verified end-to-end on Wear OS 36 emulator-5556 against a live local
server:
- 4 server cases populate the list within ~150 ms of app start
- Tap Neu → mic permission → record → stop completes in <3 s of UI
- Sync service uploads, server transcribes (whisper) + classifies
(ollama), watch's burst-poll hits within 2 s of upload-success and
merges the OnelinerState.Empty (silence rule) back into the marker
- unsynced/ ends empty (deletePair after ACK), cases/ has 5 markers
with synced_to_server=true, snapshot_cache.json on disk
After a successful upload the worker self-kicks a BurstPoll(caseId, now+60s)
into its own kick channel. While a burst is active, currentPollIntervalMs()
returns 2 s instead of the 30 s default, giving the doctor a chance to see
the LLM-generated oneliner before they swipe away from the case.
Burst exits on either of:
- the response carries a non-null oneliner for the named case
- the 60 s budget elapses
Implemented as worker-internal state — no Service plumbing changes, the
existing kick channel is the medium. SyncService still receives external
BurstPoll kicks via Intent (already wired in Phase 4) so the launcher path
remains usable, but the post-upload self-kick covers the primary use case.
2 new tests (kick-on-upload + budget-expiry-resets-interval). 73 tests
green total.
OnelinersClient does GET /api/oneliners with X-API-Key + If-None-Match,
classifies 200/304/transient/network. Mirrors
doctate-client-core::server_sync::poll_once exactly. JSON parsing lives
in domain.OnelinersJson (org.json) so the wire DTOs are first-class
in-memory types.
SnapshotCache persists the last successful response + its ETag in
filesDir/recordings/snapshot_cache.json. SyncWorkerLoop primes the
case store from this cache on cold start before the first network
call, so the watch never flashes an empty list while the service
boots.
Worker loop integration: when the pending queue is empty and a poller
is wired, runOnce polls instead of just publishing Idle. Success runs
mergeServerSnapshot + reconcileWithServerSnapshot, then writes the
new snapshot to the cache. Phase 4's poller-null behaviour remains as
the test/skeleton path.
13 new tests (OnelinersJsonTest 3, OnelinersClientTest 6, SnapshotCacheTest
4) covering parse round-trip, 200/304/transient/network classification,
If-None-Match header presence, corrupted-cache resilience. 71 tests
green total.
CaseListScreen shows a small ☁↑N at the top whenever the worker has
queue items; per-row ↑ next to the timestamp marks individual cases
that are still mid-upload. Both surface the SyncStateProvider directly
so the user sees the queue draining in real time.
MainActivity prompts for POST_NOTIFICATIONS on Wear OS 13+ — the
foreground service runs either way, but on API 33+ the persistent
notification only renders if the runtime grant is given. Result is
informational; we don't gate the recording flow on it (the doctor
still needs to be able to dictate even after a 'deny').
SyncWorkerLoop is the upload+poll core, mirrored from
doctate-client-core::server_sync::run. Pending uploads have priority
over polling (no point asking the server for state if we still hold
the doctor's audio). Backoff is in-process state — after restart it
drops back to 2s and gives the server one fresh chance, which beats
'wait 60s because we cancelled mid-backoff'.
Architecturally split into runOnce (single iteration, suspends only
on real I/O) and run (infinite loop, suspends on idle). The split
makes the loop directly testable on JVM virtual time without dealing
with advanceUntilIdle vs. infinite-while semantics — tests call
runOnce N times and assert in between.
Wired through:
- SyncService (foregroundServiceType=dataSync, low-importance silent
notification, ServiceCompat.startForeground for API 34+)
- SyncServiceLauncher replaces NoopSyncTrigger in DoctateApp
- DoctateApp.onCreate kicks the service after StartupCleanup if the
pending queue is non-empty (recovery from crash/reboot)
- AndroidManifest: FOREGROUND_SERVICE / FOREGROUND_SERVICE_DATA_SYNC /
POST_NOTIFICATIONS perms; service declaration
6 SyncWorkerLoopTest cases (success/transient/terminal/idle/fifo plus
backoff-resets-after-success). 58 tests green total.
Brummel