# Bugfix Requirements Document

## Introduction

After submitting a valid waist measurement on the Track Visceral Fat Screen, the user receives no visual feedback — no success snackbar and no navigation back to the previous screen. The data is actually saved (confirmed by a duplicate error on a second press), but the UI appears frozen. This violates Requirement 6.6 of the visceral-fat-tracking spec which mandates a success snackbar and back-navigation upon successful save.

The root cause is a state-handling race condition: the BlocListener's `_isLoading` guard is consumed by the intermediate `HealthDataLoading` state emitted inside the BLoC's `_onAddWaistEntry` handler before the `HealthDataOperationSuccess` state arrives. When the success state finally emits, `_isLoading` is already false and the listener ignores it.

## Bug Analysis

### Current Behavior (Defect)

1.1 WHEN the user submits a valid waist measurement THEN the system saves the entry but does not display a success snackbar
1.2 WHEN the user submits a valid waist measurement THEN the system saves the entry but does not navigate back to the previous screen
1.3 WHEN the user submits a valid waist measurement THEN the BlocListener resets `_isLoading` to false upon receiving the intermediate `HealthDataLoading` state, causing it to ignore the subsequent `HealthDataOperationSuccess` state
1.4 WHEN the user presses the save button a second time after the first save silently succeeded THEN the system emits a duplicate entry error (confirming data was persisted on the first attempt)

### Expected Behavior (Correct)

2.1 WHEN the user submits a valid waist measurement THEN the system SHALL display a success snackbar with the message "Waist measurement saved successfully"
2.2 WHEN the user submits a valid waist measurement THEN the system SHALL navigate back to the previous screen after showing the success snackbar
2.3 WHEN the HealthDataBloc emits `HealthDataOperationSuccess` with operationType 'add_waist' THEN the BlocListener SHALL process the success state regardless of any intermediate loading states emitted before it
2.4 WHEN the HealthDataBloc emits a `HealthDataError` after submission THEN the system SHALL display an error snackbar and remain on the screen with the entered data preserved

### Unchanged Behavior (Regression Prevention)

3.1 WHEN the user submits an invalid waist measurement (out of range, empty, or non-numeric) THEN the system SHALL CONTINUE TO prevent submission and display validation errors
3.2 WHEN the HealthDataBloc emits a duplicate entry error THEN the system SHALL CONTINUE TO display an error snackbar and remain on the screen
3.3 WHEN the user saves height or gender via the profile prompts THEN the system SHALL CONTINUE TO display the appropriate success snackbar without navigating away
3.4 WHEN the user interacts with other BLoC-driven screens (weight, blood pressure, mood entry) THEN those screens SHALL CONTINUE TO show success feedback and navigate correctly (no regression from this fix)
3.5 WHEN the user submits a valid waist measurement THEN the system SHALL CONTINUE TO persist the Waist_Entry to the database via the HealthDataBloc
