# pos-service-buttons

_Witnessed 2026-09-04T06:12:58.722Z — QRATE-UAT-1_

_A diner at a restaurant that takes orders through its own POS should not be offered a Call-Waiter bell. This walk compares **two restaurants that both have real menus** - one POS-gated, one not - so that an absent button means the gate worked, rather than meaning the menu was empty._

### 01 · PATRON

**I expected:** at a restaurant that is NOT on POS, I can call a waiter

**I saw:** 9 dishes on screen, and a service control is there: "Call staff or request the check". Service-ish handles present: layout-service-button

### 02 · PATRON

**I expected:** at a restaurant that IS on POS, that bell is not offered to me

**I saw:** 20 dishes on screen - a real, populated menu - and no service control anywhere. A sweep for service/waiter/check/bill/bubble/cutlery across the whole page finds 0 handles. The menu renders normally otherwise, so this is the gate working, not a blank page.

### 03 · PATRON

**I expected:** the difference between the two is the bell, and only the bell

**I saw:** Both menus render (9 dishes vs 20). The non-POS restaurant offers 1 service control; the POS one offers 0. That is the promise this journey makes, and a diner can see it.

---

**Verdict:** WALKED

**Why it ended here:** The behaviour holds where it can actually be seen: on a POS restaurant with a real 128-item menu the Call-Waiter bell is absent, and on a populated non-POS menu it is present. That OVERTURNS my earlier reading - I called this a false green because the only gated fixture was empty, which made absence unprovable. With a populated gated restaurant the confound is gone and the product does what it promises. What remains true is narrower and still worth saying: the CANARY itself never renders a screen - it asserts a JSON field - and it points at a fixture with zero items, so no canary anywhere proves the diner's UI hides the button. That is a coverage gap in the test, not a defect in the product.