# BF-BUG-001: customer can view staff workspace and another customer's booking

- Status: Verified on release 1.1 for the original Alex/customer staff-workspace viewing case in BF-RUN-003 on 2026-10-15. Broader permission/action coverage pending; original 1.0 failure retained.
- Requirement: BF-REQ-02, customer/staff permission matrix.
- Case / run: BF-TC-002 / BF-RUN-002.
- Environment: Windows desktop, Chrome (versions unrecorded); release 1.0 confirmed in image; Alex Rivera / Customer.
- Date: 2026-10-14.
- Provenance: learner-authored steps and expected denial from supplied goal; coached credential correction; learner execution/report/screenshot; assistant-formatted defect record and proposed triage.

## Reproduction

1. Select release 1.0 and reset to the sample fixture as specified in the reviewed plan.
2. Choose Alex Rivera — customer and sign in using Practice123.
3. Confirm the displayed role is Customer.
4. Select Staff workspace and inspect content, without executing management actions.

Expected: an access-denied explanation, with no other customer details or staff management interface exposed. A visible navigation button is permitted by the requirement.

Actual: the staff workspace opens. [Evidence](../evidence/session-01/BF-RUN-002_v1.0_customer-staff-workspace-visible.png) shows Sam Patel's BF-001 Volunteer briefing, Studio A, 2026-11-17, 10:00–11:00, 4 people, plus Alex's BF-002. The Block room time form and Cancel booking controls are visible. No access-denied explanation appears.

## Impact, triage, and limits

In this simulated workflow, a customer can see another customer's name and booking details and is presented with staff management controls. Successful use of those controls has not been tested. Do not report proven cancellation/block creation or unrestricted modifications from this screenshot.

Coach-proposed severity: High for violating customer/staff data visibility. Coach-proposed priority: High, because the role boundary should be restored before treating the staff workflow as acceptable. These are teaching/triage suggestions, not a business-approved ranking or the learner's own prioritization. No repeat frequency is established beyond this one reported run.

This is a local role simulation using fictional data. It is not evidence of a vulnerability in a production service or real server authorization.

## Retest

BF-RUN-003 repeated the Alex/customer → Staff workspace action on 1.1. The learner reports denied access; the [screenshot](../evidence/session-02/BF-RUN-003_v1.1_alex-staff-access-denied.png) shows the correct customer identity/release and “Staff access required” explanation, with no staff contents/actions visible. Outcome: **Pass**, verifying the original viewing observation for Alex on 1.1.

The 1.0 failure remains in the history. Successful management actions were never established by the original screenshot, and this retest does not independently establish all action enforcement or all roles.

Related regression comparison: BF-RUN-004 subsequently passed on 1.1. [Morgan Staff evidence](../evidence/session-02/BF-RUN-004_v1.1_morgan-staff-access-allowed.png) shows legitimate staff access with both sample customer bookings and management controls visible. This supports authorized viewing alongside customer denial; it does not establish successful management mutations.