BioFlow Requirements
System Test Specifications
  • SYS-001
    change in progress 1. First-launch readiness for local enrolment UID: SYS-001 TYPE: functional STATUS: Approved RELATIONS (Child): STATEMENT:

    When the device is opened on a workstation that has no pre-existing BioFlow data directory, a default local clinic shall be present and immediately available for the clinician to attach newly-enrolled patient records, without requiring the clinician to first create or configure a clinic record manually.

     RATIONALE:

    Stakeholder commitment: clinicians installing the device on a fresh workstation expect to enrol their first patient within minutes of starting the application, without learning a separate clinic-management workflow as a prerequisite. Auto-provisioning a default local clinic removes that friction.

     REVIEWED_HASH:

    1c8a5a84aebeb1b05f0044436dce6685870daaaade275946cde09b1b935e7fc5

     REVIEWED_BY:

    @DougYoungberg
  • SRS-001
    change in progress 1. First-launch database initialisation UID: SRS-001 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    On first launch, when no database file exists at the configured application data path, the software shall create the local database, apply the current schema version, and create a default local clinic record that serves as the container for locally-created patient records.

     RATIONALE:

    Refines SYS-001: the software-level mechanism that realises the device's first-launch readiness commitment. Establishes the minimum persistent state required for any subsequent clinical operation — without it, patient records cannot be stored and recording sessions cannot be attached to a patient.

     REVIEWED_HASH:

    98b05f66e64fdd504ec9ab458d051d1bf7ac6ef1cc6703c83eec0bbfcfa52d83

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-001 on clean install — fresh workstation, first launch, verify the local clinic is visible in the Patients menu.
ST-001
change in progressSkipped 1. Local clinic visible in Patients menu UID: ST-001 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

1abfb93d30805f56ec9159fab5db3477d395bc27c4bc8ac0c6b4aac3b6164005

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-005
    change in progress 5. Audit-trail review and export UID: SRS-005 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall present the local audit trail to an authorised operator in a form that lists each entry's action, affected record, and system timestamp, ordered by time. The software shall additionally provide a means to export the current audit trail to a file in a portable, human-readable format that preserves the same fields as the on-screen presentation, so that the exported file can be examined off the device by an auditor or by the clinical organisation's own information-security review.

     RATIONALE:

    Refines SYS-004. Capturing audit entries in the local database is necessary but not sufficient: the entries live inside the encrypted application database, which an internal reviewer or external auditor is not expected to access directly. The device therefore surfaces the trail to an authorised operator inside the application and provides an exportable copy that can be examined off the device. Without a viewer-and-export surface, the audit trail is opaque to the clinical organisation's own review duties — the entries exist but cannot be examined without direct access to the encrypted database file. The "human-readable" wording is deliberate: a binary or schema-coupled export defeats the off-device review use case, which is conducted by people reading entries on a workstation other than the device. The "ordered by time" presentation rule keeps the on-screen view faithful to the chronology of operations; the export preserves the same fields so that the exported copy is a copy of the on-screen trail rather than a transformation of it.

     REVIEWED_HASH:

    3da5c78892fc7f563c2fd96cb6b7e93ad305672d437b12b2a59dd039044ad207

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-006 verifies the export round-trip — written audit entries appear in the exported file with the same fields and content. ST-002 (planned, to be authored once the viewer surface ships) verifies an operator can locate the audit trail in the application, see the expected entries, and invoke the export from the workstation.
ST-002
change in progressSkipped 2. Operator can review and export the local audit trail UID: ST-002 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

6af8b30c75fbc477db2f17b298fc62512d592e088d96999e86ae00fba8c4705b

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-004
    change in progress 4. Audit logging of clinical record operations UID: SRS-004 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall write one audit-log entry for each of the following operations on local clinical records: creation, modification, and deletion of a patient; start, stop, and deletion of a recording; and successful upload of a recording to the cloud. Each entry shall carry the action, the identifier of the affected record, and a system-generated UTC timestamp. After an entry is written, the software shall not modify it in a way that obscures previously recorded information, and shall not delete audit entries.

     RATIONALE:

    Refines SYS-004. The list of audited operations corresponds to the operator-initiated mutations and exports of patient or recording data that the application currently exposes. Clinic and clinical-user mutations are not in scope because the application does not permit those operations on the local workstation — clinics are read-only mirrors of an external cloud directory the device is configured to sync with; clinical users are authenticated rather than created in-app. The required content per entry (action, target, time) is the minimum that lets an audit reviewer reconstruct what happened: which clinical record was affected, what action was performed, and when. The immutability clause expresses the underlying invariant that an audit entry must remain a faithful record of the operation it describes; an application-layer path that overwrites the details of a prior entry would functionally be a record change that obscures original information, and is therefore prohibited.

     REVIEWED_HASH:

    8670efd17561286bd5396fe9d81ff480539400a00719b06c3f4619af3242feb4

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-004 exercises the audit chain end-to-end by invoking each of the audited operations through the application's use-case pathway (or the corresponding production caller when no use case exists) and asserting that the audit-log entry is written with the correct action, target identifier, and system-generated timestamp. IT-005 verifies the data-shape and immutability commitments — entries have the required fields and an existing entry's content cannot be changed after write.
ST-003
change in progressSkipped 3. Audit trail captures every operator-initiated clinical record operation UID: ST-003 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

f1b89562a9ab7e5eb067776f5ed4112f487dbe33a551b39139ac9dccbd6c2dd8

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
ST-004
reviewedSkipped 4. Main window maximised on launch UID: ST-004 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

35a6ff9d436d21c3d6f8cf83ad53a40df20ebd21b1762fba472114b03b64d688

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-007
    reviewed 7. Always-visible recording control widget UID: SRS-007 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall display a recording control widget anchored to the top of the main window, and shall keep that widget visible in all interaction states, including signal-control mode, menu mode, and while any overlay is open.

     RATIONALE:

    Refines SYS-005. The recording controls govern the active session — its start, its stop, and its running status. Keeping the widget visible in every interaction state ensures the operator can always see and reach the recording controls without first dismissing a menu or overlay.

     REVIEWED_HASH:

    bccb9886c2528cb600bccee06daef365798ce97ad2887816160909f6270bd10f

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST item (planned) — verify the recording control widget remains visible in signal-control mode, menu mode, and while an overlay is open.
ST-005
reviewedSkipped 5. Recording widget visible across states UID: ST-005 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

50ee55956b278d705943373e174457601218236c278edf1241a5dcca3f424a5d

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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).
  • SRS-008
    reviewed 8. Bottom-bar signal and menu mode toggle UID: SRS-008 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall provide a bottom bar that switches between a signal-control mode and a menu mode when the operator activates the bottom-bar mode toggle.

     RATIONALE:

    Refines SYS-005. A single bottom bar that switches between signal-control functions and menu functions keeps both sets of controls reachable from one fixed location, without permanently consuming screen area that would otherwise reduce the live signal display.

     REVIEWED_HASH:

    a2bd1b9f841162a89db68d43b7a5e544d65872f6e094573158396d0f6e6f4943

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST item (planned) — verify activating the bottom-bar toggle switches the bar between signal-control mode and menu mode.
  • SRS-011
    reviewed 11. Signal-mode bottom-bar controls UID: SRS-011 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    In signal mode, the bottom bar shall present the signal-parameter controls: a high-pass filter, a low-pass filter, a notch filter, a sensitivity control, a timebase control, and a montage selector.

     RATIONALE:

    Refines SYS-005. These are the per-recording signal adjustments the operator reaches without leaving the signal view; presenting them on the bottom bar in signal mode keeps them one interaction away while the live signal remains visible.

     REVIEWED_HASH:

    87a993af0ca2801932f9df334a3860d5e9de62d699450987430e7dd994b65a07

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-011 asserts the six controls render in signal mode; ST-006 confirms the signal-parameter controls are shown at the operator-facing tier.
  • SRS-012
    reviewed 12. Menu-mode bottom-bar navigation buttons UID: SRS-012 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    In menu mode, the bottom bar shall present the navigation buttons: Patients, Montages, Settings, and Activities.

     RATIONALE:

    Refines SYS-005. Menu mode replaces the signal-parameter controls with the four primary navigation destinations, each of which opens its overlay, so the operator reaches patients, montages, settings, and activities from the same fixed bar.

     REVIEWED_HASH:

    68a5f126aba7210ab6bfdf3c3998fa61d7efa723f3b4cd42215e59a1f7fd2099

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-011 asserts the four navigation buttons render in menu mode; ST-006 confirms the four items are shown at the operator-facing tier.
ST-006
reviewedSkipped 6. Bottom bar toggles signal and menu modes UID: ST-006 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

4efc230698735603fb7956284db0f435b55ca922edf621eed359c7faa6d6236b

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-009
    reviewed 9. Dismiss overlay on ESC or click-outside UID: SRS-009 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall dismiss the active navigation overlay when the operator either presses the ESC key or clicks outside the overlay's content area.

     RATIONALE:

    Refines SYS-005. Navigation overlays float above the live EEG signal; providing the conventional dismissal gestures — ESC and click-away — lets the operator return to the unobstructed signal view quickly. An overlay with in-progress edits is guarded against accidental dismissal (see ARCH-010), so the dismissal applies to overlays that permit it.

     REVIEWED_HASH:

    b262c063b65c057df8f8d5f2d6aaaa0541cee3f7eb9887b695ffdbca7577e649

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-007 opens a navigation overlay and verifies it is dismissed both by pressing ESC and by clicking outside the overlay content.
ST-007
reviewedSkipped 7. Overlay dismissed by ESC and click-outside UID: ST-007 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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).

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

72067e7cf69fea627570fb8ea7644f0a7da979ee6c76f1427d850f41c272186c

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-010
    reviewed 10. At most one overlay open at a time UID: SRS-010 TYPE: functional STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall display at most one navigation overlay at a time; opening an overlay shall replace any overlay that is currently open.

     RATIONALE:

    Refines SYS-005. Limiting the interface to a single open overlay keeps the operator's focus clear and preserves the maximum visible area of the underlying signal display. The constraint is realised structurally by a single selected-overlay index rather than a navigation stack (see ARCH-010), so a second overlay cannot be layered over the first.

     REVIEWED_HASH:

    8b339f513a68052b72a0dab34f0ebc46b778848c38b8552a70abe5c96c660985

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-008 opens one overlay, then opens a second, and verifies only the second is shown.
ST-008
reviewedSkipped 8. Only one overlay shown at a time UID: ST-008 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

9542be12e77de13936787b1148b34a5e3ac255d13614bf06786f45a54578f1a0

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
ST-009
reviewedSkipped 9. Recorded duration shown in HH:MM:SS UID: ST-009 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

c835f5c0a49fa0c891b7b173bff611254eeaf46b8f27d8c705369bede403c5a0

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-014
    reviewed 14. Patient name in recording widget UID: SRS-014 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    While a patient is selected, the software shall display the selected patient's name in the recording control widget.

     RATIONALE:

    Refines SYS-005. Showing the selected patient's name in the always-visible recording widget lets the operator confirm at a glance which patient the session is being recorded for while keeping the live signal in view.

     REVIEWED_HASH:

    3e52266db5d5faf9cfd839c7b4b8808bea0f43f535ef0af241b4cb0e72ffe88f

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-010 observes the selected patient's name shown in the recording widget in the running application; IT-008 confirms the widget renders the patient name from seeded state.
ST-010
reviewedSkipped 10. Patient name shown in recording widget UID: ST-010 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

With the application launched, the operator shall select a patient and then see that patient's name displayed in the recording control widget.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

a067526d3644efec1a8527ec7873c5863690f6abb9880ad13b74fa95d1afc0e4

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-015
    reviewed 15. Bottom bar default and resting mode UID: SRS-015 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The bottom bar shall be in signal mode when the application launches, and shall return to signal mode whenever the open navigation overlay is dismissed.

     RATIONALE:

    Refines SYS-005. Signal mode is the operator's working view, so the bottom bar opens there and falls back to it once a navigation overlay is closed, keeping the signal-parameter controls available by default.

     REVIEWED_HASH:

    9c6b9513d6834a87fc4441c8cea891e78a3add74b32609de21884fb0a816ea9e

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: IT-009 asserts signal mode at launch and IT-010 asserts the return to signal mode after the overlay is dismissed; ST-011 observes the launch-to-menu-to-signal cycle at the operator-facing tier.
ST-011
reviewedSkipped 11. Bottom bar rests in signal mode UID: ST-011 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

018cf2cc5768863e4f86a4e19ca00bbfc3d111583babbe87b480fb78e362a8a5

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.
  • SRS-016
    reviewed 16. Minimum main window size UID: SRS-016 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall prevent the main application window from being resized smaller than 1024 by 768 pixels.

     RATIONALE:

    Refines SYS-005. 1024 by 768 is the minimum size at which the operator workstation remains usable; preventing the window from shrinking below it keeps the live signal display and recording controls legible on lower-resolution laptops.

     REVIEWED_HASH:

    4200fb2d0be3aee20b1455b9e0faba8eab18e82f2097544c2a0921230dd51767

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-012 (planned) resizes the window below the minimum and asserts the reported window bounds are clamped to at least 1024 by 768 at the operator-facing tier. No flutter_test integration test is feasible — the minimum is enforced natively by the window_manager package, not in a widget tree.
ST-012
reviewedSkipped 12. Minimum window size is enforced UID: ST-012 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

With the application launched, attempt to resize the main window below the 1024x768 minimum and confirm the window is clamped to at least 1024x768.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

fb85a16be79bc3682b6794803a37235605338f1042ffa054ac691aa09715008b

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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).
  • SRS-017
    reviewed 17. Selectable application themes UID: SRS-017 TYPE: ui STATUS: Approved RELATIONS (Parent): RELATIONS (Child): STATEMENT:

    The software shall provide three selectable visual themes — Light, Dark, and Dark Glass — and shall apply the operator's selected theme across the application.

     RATIONALE:

    Refines SYS-005. Offering Light, Dark, and Dark Glass themes lets the operator pick the appearance that suits the room's lighting and their preference, while the selection applies consistently across the workstation.

     REVIEWED_HASH:

    5e1badbc2e307e77ef9e1d06d69e677c0706f21a32b6a1d144b64768213b4160

     REVIEWED_BY:

    @DougYoungberg

     NOTES:

    coverage-plan: ST-013 observes the three themes offered and a theme change taking effect in the running application; IT-012 verifies that each theme type drives its application theme at the integration tier.
ST-013
reviewedSkipped 13. Operator selects each visual theme UID: ST-013 TEST_METHOD: automated TEST_TOOL: VisionTrace STATUS: Approved RELATIONS (Parent): STATEMENT:

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.

 ACCEPTANCE_CRITERIA:

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.

 REVIEWED_HASH:

369cb469593e893924d66d1d50d7089e4754a2c91ecd93e769290e920f029396

 REVIEWED_BY:

@DougYoungberg

 NOTES:

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.