System Test Specifications
With the application launched on a workstation that has no pre-existing BioFlow data directory, navigate to the Patients menu and open the clinics dropdown. The local clinic entry shall be visible in the dropdown.
Preconditions: application is launched on a clean workstation (no prior data directory); the main screen is visible. Steps: navigate to the Patients menu; open the clinics dropdown. Verification: a VisionTrace AI agent.verify(...) call confirms the local clinic is visible in the dropdown. No error dialog appears during launch or navigation.
1abfb93d30805f56ec9159fab5db3477d395bc27c4bc8ac0c6b4aac3b6164005
@DougYoungberg
Launching the application on a clean workstation is a test precondition handled by the VisionTrace app_session fixture, not a step in the test body. Test code lives in this repo at visiontrace_tests/bioflow/st001/, decorated with @visiontrace_test_case("ST-001"). The agent.verify(...) call takes a screenshot of the current UI and asks an AI model to confirm the described condition — for this test, that the local clinic is present in the dropdown. Running this test in CI requires VisionTrace to be installed in the CI environment and a Windows runner with a usable desktop session. Multi-link verifies SYS-001 (operator can enrol on first launch) and SRS-001 (software creates default clinic); both close via this same end-to-end observation.
With the application launched, the operator shall be able to perform an audited clinical operation, locate the resulting entry in the on-screen audit-trail review surface, and export the audit trail to a workstation-side file from the same surface. The operator performs a patient creation and a patient deletion (representative audited clinical operations), then opens the Activities overlay and selects the Audit Log tab. The audit entries corresponding to the two operations shall be visible there. The operator then invokes Export CSV, completes the platform save-file dialog, and the application shall confirm a successful export.
Preconditions: application is launched; the main screen is visible. Steps: create a patient with a known first/last name through the patient-management surface; delete that same patient through the same surface; open the Activities overlay; select the Audit Log tab; invoke Export CSV; complete the save-file dialog with a workstation-side path. Verification: a VisionTrace agent.verify(...) call confirms that the Audit Log tab lists at least one entry for the patient creation and one entry for the patient deletion, each naming the patient and showing a system timestamp; a second verify(...) call confirms that after the save-file dialog completes the application surfaces a success indication (success snackbar or toast) reporting that the audit log has been exported. No error dialog appears during any step.
6af8b30c75fbc477db2f17b298fc62512d592e088d96999e86ae00fba8c4705b
@DougYoungberg
Coverage: ST-002 verifies the SRS-005 / ARCH-006 commitment at the operator-facing altitude — that the audit trail is reviewable and exportable through the application's UI, not only via the underlying repository. IT-006 verifies that the exported file is a faithful copy of the trail at the file-content level; ST-002 verifies that an operator can reach that file through the UI flow. The two are complementary: IT-006 would still pass if the Export buttons were never wired up (a non-conformance ST-002 catches), and ST-002 would still pass if the exported file were silently corrupted (a non-conformance IT-006 catches).
Out of scope for ST-002: recording lifecycle (start/stop/upload/ delete). These are verified end-to-end at the integration tier by IT-004 and need not be re-verified here. Patient CRUD is sufficient to demonstrate the operator-facing review-and-export path.
Test code lives in this repo at visiontrace_tests/bioflow/st002/, decorated with @visiontrace_test_case("ST-002"). The save-file dialog is the platform-native Windows dialog driven by the file_picker package; the recording must capture typing a known temp path and clicking Save so the file is actually written and the success snackbar appears.
With the application launched, the operator shall perform each audited clinical-record operation through the UI — patient creation, patient update, recording start, recording stop, recording deletion, and patient deletion — and the audit trail surfaced in the Audit Log tab shall contain one entry per operation, naming the affected patient or recording. Recording is exercised against the device's playback signal source so the test does not depend on a live amplifier.
Preconditions: application is launched; the main screen is visible; the playback signal source is available. Steps: create a patient with a known first/last name; edit a field on that patient and save; start playback; start a recording; stop the recording; delete the recording from the recent recordings list; delete the patient; open the Activities overlay and select the Audit Log tab. Verification: a VisionTrace agent.verify(...) call confirms the Audit Log tab lists six entries for the test patient and recording in newest-first order — one whose title indicates a patient creation, one a patient update, one a recording start, one a recording completion, one a recording deletion, and one a patient deletion — each carrying a system timestamp. No error dialog appears during any step.
f1b89562a9ab7e5eb067776f5ed4112f487dbe33a551b39139ac9dccbd6c2dd8
@DougYoungberg
Coverage: ST-003 verifies the SRS-004 commitment at the operator- facing altitude — every audited operation an operator can perform through BioFlow's UI produces an audit entry the operator can see. IT-004 verifies the same SRS-004 commitment exhaustively at the integration tier by invoking each operation through its production use-case pathway; ST-003 demonstrates the same commitment at the UX surface using one representative patient and one representative recording. The two are complementary: IT-004 would still pass if a UI control failed to invoke its use case (a regression ST-003 catches); ST-003 would still pass if the audit-write inside the use case were silently dropped (a regression IT-004 catches).
Out of scope for ST-003: recording upload. The audit-write half of that operation is exhaustively verified at the integration tier by IT-004 (g) (production UploadManager path against a real audit service), and the operator-facing visibility half is already verified by ST-002 (the Audit Log tab surfaces every entry regardless of which use case produced it). Adding upload here would add cloud-credential and network dependencies without adding new compliance evidence.
Out of scope for ST-003: review and export of the trail. ST-002 covers the operator-facing review and export commitments (SRS-005).
Test code lives in this repo at visiontrace_tests/bioflow/st003/, decorated with @visiontrace_test_case("ST-003"). The recording-lifecycle steps depend on the playback signal source being available on the test workstation.
With the application launched on the workstation, the main application window shall be displayed maximised, filling the available screen work area, with the EEG signal area occupying the main region.
Preconditions: the application is launched; the main screen is visible. Steps: observe the main window immediately after launch. Verification: a VisionTrace agent.verify(...) call confirms the application window is maximised — it fills the screen work area and the signal display occupies the main region rather than appearing in a small or floating window. No error dialog appears during launch.
35a6ff9d436d21c3d6f8cf83ad53a40df20ebd21b1762fba472114b03b64d688
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st004/, decorated with @visiontrace_test_case("ST-004"). Launching the application is a precondition handled by the VisionTrace app_session fixture, not a test step. Verifies SRS-006 at the operator-facing altitude; the launch-maximise mechanism it exercises is described by ARCH-007, which carries no flutter_test integration test because that path (native runner plus window_manager singleton) is not injectable.
With the application launched, the recording control widget at the top of the main window shall remain visible as the operator moves between interaction states: in the default signal mode, after switching the bottom bar to menu mode, and while a navigation overlay is open.
Preconditions: the application is launched; the main screen is visible. Steps: observe the top of the main window in the default signal mode; activate the bottom-bar toggle to enter menu mode (which opens a navigation overlay); observe the top of the window again. Verification: a VisionTrace agent.verify(...) call confirms the recording control widget is visible at the top of the window in signal mode, and a second agent.verify(...) call confirms it is still visible at the top once the bar is in menu mode with the navigation overlay open. No error dialog appears during any step.
50ee55956b278d705943373e174457601218236c278edf1241a5dcca3f424a5d
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st005/, decorated with @visiontrace_test_case("ST-005"). Verifies SRS-007 at the operator-facing altitude (the always-visible commitment across UI states); IT-008 verifies the recording widget's rendering at the integration tier (ARCH-008).
With the application launched, the bottom bar shall begin in signal mode showing the signal-parameter controls; activating the bottom-bar toggle shall switch it to menu mode showing the Patients, Montages, Settings, and Activities navigation items; activating the toggle again shall return it to signal mode.
Preconditions: the application is launched; the main screen is visible with the bottom bar in its default signal mode. Steps: observe the bottom bar; activate the centre toggle control; observe the bottom bar; activate the centre toggle control again; observe the bottom bar. Verification: a VisionTrace agent.verify(...) call confirms the bottom bar shows signal-parameter controls initially; a second confirms it shows the Patients/Montages/Settings/Activities navigation items after the first toggle; a third confirms it has returned to the signal-parameter controls after the second toggle. No error dialog appears during any step.
4efc230698735603fb7956284db0f435b55ca922edf621eed359c7faa6d6236b
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st006/, decorated with @visiontrace_test_case("ST-006"). Verifies SRS-008 at the operator-facing altitude; IT-009 verifies the widget-to-view-model mode switching at the lower tier.
With the application launched, the operator shall open a navigation overlay and dismiss it by pressing ESC, then open it again and dismiss it by clicking outside the overlay content; in each case the overlay closes and the underlying main view is shown again (the signal area may show the "Signal display inactive" placeholder when no signal is streaming).
Preconditions: the application is launched; the main screen is visible. Steps: open a navigation overlay (switch the bottom bar to menu mode so the Patients overlay opens); press ESC; observe; open the overlay again; click an empty area outside the overlay panel; observe. Verification: a VisionTrace agent.verify(...) call confirms the overlay is no longer shown after the ESC press, and a second agent.verify(...) call confirms the overlay is no longer shown after clicking outside it. No error dialog appears during any step.
72067e7cf69fea627570fb8ea7644f0a7da979ee6c76f1427d850f41c272186c
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st007/, decorated with @visiontrace_test_case("ST-007"). Verifies SRS-009 at the operator-facing altitude; IT-010 verifies the dismissal mechanism (clearSelection) at the integration tier.
With the application launched, the operator shall open a navigation overlay and then switch to other overlays in turn; at each switch only the newly-opened overlay shall be shown, with the previously-open overlay no longer visible.
Preconditions: the application is launched; the main screen is visible. Steps: open the Patients overlay (switch the bottom bar to menu mode), then in turn open Montages, then Settings, then Activities via their bottom-bar navigation items. Verification: after each switch a VisionTrace agent.verify(...) call confirms the newly-selected overlay is shown and the previously-open overlay is no longer visible — i.e. only one overlay is visible at a time. No error dialog appears during any step.
9542be12e77de13936787b1148b34a5e3ac255d13614bf06786f45a54578f1a0
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st008/, decorated with @visiontrace_test_case("ST-008"). Verifies SRS-010 at the operator-facing altitude; IT-010 verifies the single-selected-index model at the integration tier.
With the application launched and a recording session active, the operator shall see the recorded-duration readout in the recording widget displayed in HH:MM:SS format.
Preconditions: the application is launched and a recording session is active, so the recording widget is in a non-idle state. Verification: a VisionTrace agent.verify(...) call confirms the recording widget shows a recorded-duration readout formatted as HH:MM:SS — two-digit hours, minutes, and seconds separated by colons (for example "00:00:07"). No error dialog appears.
c835f5c0a49fa0c891b7b173bff611254eeaf46b8f27d8c705369bede403c5a0
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st009/, decorated with @visiontrace_test_case("ST-009"). Verifies SRS-013 at the operator-facing altitude; UT-001 verifies the duration-to-HH:MM:SS formatting at the unit tier and IT-008 confirms the widget renders the readout from seeded state.
With the application launched, the operator shall select a patient and then see that patient's name displayed in the recording control widget.
Preconditions: the application is launched; the main screen is visible. Steps: open the Patients overlay (switch the bottom bar to menu mode) and select a patient from the list. Verification: a VisionTrace agent.verify(...) call confirms the recording control widget shows the selected patient's name. No error dialog appears.
a067526d3644efec1a8527ec7873c5863690f6abb9880ad13b74fa95d1afc0e4
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st010/, decorated with @visiontrace_test_case("ST-010"). Verifies SRS-014 at the operator-facing altitude; IT-008 confirms the widget renders the patient name from seeded state.
With the application launched, the operator shall see the bottom bar in signal mode, switch it to menu mode, then dismiss the open overlay and see the bottom bar return to signal mode.
Preconditions: the application is launched; the main screen is visible. Steps: confirm the bottom bar shows the signal-parameter controls; switch the bottom bar to menu mode, which opens a navigation overlay; dismiss the overlay by pressing Escape. Verification: agent.verify(...) calls confirm the bottom bar shows the signal-parameter controls at launch and again after the overlay is dismissed, i.e. it has returned to signal mode. No error dialog appears.
018cf2cc5768863e4f86a4e19ca00bbfc3d111583babbe87b480fb78e362a8a5
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st011/, decorated with @visiontrace_test_case("ST-011"). Verifies SRS-015 at the operator-facing altitude; IT-009 asserts signal mode at launch and IT-010 asserts the return to signal mode after the overlay is dismissed.
With the application launched, attempt to resize the main window below the 1024x768 minimum and confirm the window is clamped to at least 1024x768.
Preconditions: the application is launched. Steps: request a window size smaller than the minimum (800x600) through the window-geometry API. Verification: the resulting window bounds are at least 1024 pixels wide and 768 pixels tall, i.e. the request was clamped to the declared minimum. The window is restored to its maximized state afterwards.
fb85a16be79bc3682b6794803a37235605338f1042ffa054ac691aa09715008b
@DougYoungberg
Hand-written geometry-assertion test (not recorder-generated) at visiontrace_tests/bioflow/st012/st_012_minimum_window_size_enforced.py, decorated with @visiontrace_test_case("ST-012"). Asserts on the actual window bounds via the VisionTrace AppSession.resize_to / get_window_bounds API rather than a visual check. Verifies SRS-016 at the operator-facing tier; no flutter_test integration test is feasible (the minimum is enforced natively by the window_manager package).
With the application launched, the operator shall open the theme selector, see the three available themes (Light, Dark, Dark Glass), and select each of the three in turn, with the application's appearance changing to match each selected theme.
Preconditions: the application is launched; the main screen is visible. Steps: open the settings / theme selector; confirm the three themes Light, Dark, and Dark Glass are listed; then select each theme in turn (first, second, third). Verification: a VisionTrace agent.verify(...) confirms all three themes are offered in the selector, and after each selection a further agent.verify(...) confirms the application's appearance reflects the just-selected theme and differs from the previous one. No error dialog appears.
369cb469593e893924d66d1d50d7089e4754a2c91ecd93e769290e920f029396
@DougYoungberg
Test code lives in this repo at visiontrace_tests/bioflow/st013/, decorated with @visiontrace_test_case("ST-013"). Verifies SRS-017 at the operator-facing altitude; IT-012 verifies the theme-type-to-theme mapping at the integration tier.