Canary Honesty Ledger

The kitchen-hours gate is right the first time it is asked and wrong the second, so a diner arriving out of hours is shown a dinner-only dish at lunchtime and is never told the kitchen is closed.

• Scanned in as a diner at lunchtime — phone on Dhaka time, reading 12:15, which is after breakfast and well before dinner.
• The server's first answer was right: menus closed, nothing on the menu.
• Then the app opened a table session and asked the same question again. That time the answer came back the other way: menu open.
• The screen then put up a dinner-only dish — Canary Dinner Special, $22.99 — and at no point told me the kitchen was shut.

Couldn’t check Why it flips. I only saw that it does — this is an observation, not a root cause. What I did notice is that open-or-closed is decided from the phone's own clock, so a traveller, or anyone whose clock is wrong, hits this on an ordinary visit.

Left behind The scan opened a table session on this fixture. Nothing else is recorded for this walk.

what I saw · trace.zip · patron video · report

WALKED PART WAY. Got 4 of 6 steps and everything worked. Did not finish, so I will not call it green.

Two of this journey's six steps skip themselves when there are no cocktails to look at, and the skip still reports as green. Real coverage is 4 of 6, permanently.

• Went looking for the cocktail banner this journey is about. It is not on any of the dev restaurants.
• The band that is on screen there is the wine sommelier - a different feature entirely.
• So I read the journey's own card: two of its six steps skip themselves whenever the test kitchen has no approved cocktails set up. It has none.
• Which means those two steps have not run in dev for as long as that kitchen has been empty - and the board still shows a plain green tick a reader will take as proof the banner works.

Couldn’t check Whether the cocktail banner works at all. There is nothing on any dev restaurant that would make it appear.

what I saw · trace.zip · patron video · report

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKABLE. This journey is mostly direct API calls with no screen to look at, so there is nothing for a person to walk.

Nothing here is visible to a person, so whether the screen behind it is reachable at all stays unknown.

• A person would need some screen where this actually shows up.
• There isn't one - the journey's own card says every step is a direct call to the server, so nothing ever opens in a browser.
• Nothing an operator can hand me fixes that; it would need the journey itself to gain a screen.

Couldn’t check Both steps. A green tick here cannot detect an unreachable screen.

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

Whether a diner could reach any of this stays unknown, because there is no screen behind it.

• A person would need a screen to look at.
• There isn't one — every step of this journey is a direct call to the server, so no browser ever opens.
• Nothing for me to unblock: it would take the journey itself covering a screen a person can reach.

Couldn’t check Anything a person would see. This would pass just the same if the screen behind it were unreachable.

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

All six steps stay unknown — a green here can't tell you whether the drink groupings are on a screen anyone can reach.

• A person would need to see drinks grouped into their sub-categories on a menu.
• They can't here: by its own description this journey never opens a browser — it only talks to the server — and the restaurant it uses has no owner attached, because the setup job strips the owner off it on every run.
• Unblocking needs the operator, or someone with database or code access, to give the restaurant an owner.

Couldn’t check All six steps.

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

None of the eight steps was graded, so a green here still cannot tell you whether a person could reach the screen at all.

• Someone would need to open a menu screen and see dishes filed under sub-categories.
• Can't: this journey's own description says every step is a direct call with no screen behind it, and the fixture has no owner attached — the setup job deletes the owner assignment every time it runs, so there is nobody to sign in as.
• Operator: the owner has to be put back on the fixture, which needs either a database change or a backend change.

Couldn’t check All eight steps.

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

Whether a diner could reach this stays unknown, because no screen is involved anywhere in it.

• A person would need a screen to look at.
• There isn't one — this journey is entirely direct calls to the server, and no browser opens at any point.
• Nothing for me to unblock: it would take the journey itself covering a screen a person can reach.

Couldn’t check Anything a person would see. A pass here would stay a pass even if the screen behind it were unreachable.

A diner can still cancel his order after a second person joins the same table — it went through cleanly, with nothing complaining.

• Sat down at table 9940 as one diner, added a dish and placed the order for real.
• Then joined the same table as a second diner in a separate browser — that is the moment this journey is about.
• Went back to the first diner's phone, opened the Ordered tab, found the cancel button and tapped it.
• No error and no failure message appeared anywhere on the screen afterwards.

Couldn’t check Whether the cancellation really landed in the records. All I have is what the diner's screen showed; I have no access to look at the order itself.

Left behind Table 9940 carries the order I placed and then cancelled, from the two guest sessions I opened on it.

The onboarding nudges come up one at a time in order, and tapping one dismisses it without another jumping in behind it.

• Sat down at table 9943 as a brand-new diner and just watched for 40 seconds.
• Three little coaching nudges came up in order — one about courses, one about filters, one about search — and never more than one on screen at a time.
• Opened a second, completely separate diner at table 9944, where the first nudge told me to swipe across to the next course.
• Tapped it and it went away. No second nudge appeared in the 15 seconds after.

You cannot poke at someone else's table by guessing — a wrong session is refused with a plain message, and the real diner sitting there is never disturbed.

• Joined table 9966 as a real guest in a browser, and the table gave me a session.
• Joined the same table again as a second guest on a second connection — it came back with the same session.
• Then pretended to be that table using a deliberately wrong session. It refused me and told me to reload.
• Tried again with the right one and it answered back normally.
• Checked that the first guest was never thrown out while I did this. He wasn't. Then left the table and closed cleanly.

Left behind Nothing — I left the table and closed my connection cleanly.

Moving from one table to another keeps your cart, warns you before it happens, and you can still order afterwards. Green, and honestly so.

• Joined table 9961 as a guest and put a Canary Iced Tea and a Canary Cola in the cart — 2 items, $6.99, prices right.
• Then moved the same page across to table 9962. The app didn't just do it: it warned me first that I was changing tables and that my cart would come with me, and made me confirm.
• After the move the cart still held both items, same quantities.
• Opened the cart again — the bar had shrunk to an icon after the move — and pressed Place order $6.99. It went through, and both items showed as ordered, total $6.99.

Left behind A placed order — Canary Iced Tea and Canary Cola, $6.99 — standing on table 9962 after the move.

Orders that ought to fail do fail, straight away, and say why in plain words. Green, and honestly so.

• This journey has no screen at all, so I drove it straight against the live server — the same conversation the app's phone connection has.
• Got a guest identity, joined table 9947, and got a session back that lasts four hours.
• Tried to order with an empty cart. It came back within seconds saying not everyone at the table was ready. No silent hang.
• Tried to order on a session that had gone stale. It came back saying the session had expired and to reload the page — exactly what the step promises.
• Left the table and the connection closed cleanly. The earlier pass's mismatch error turned out to be my own test rig, not the product; I ran three stale-session variations side by side to tell them apart.

Couldn’t check This was driven against the server rather than through a browser, so nothing here shows what a diner would actually be shown on screen.

Left behind Nothing — I left the table and the connection closed cleanly.

On a restaurant that isn't on the till programme, the diner still gets the full service drawer, which is exactly what should happen.

• Checked first that this restaurant is deliberately NOT on the till programme, and that all four of its hide-this-from-the-diner settings are present and switched off. That is the baseline this journey needs.
• Then sat down as a real guest at table 9963 and tapped the service button in the bottom-right corner.
• The service drawer opened on the right table, offering three live actions — call the waiter, ask for silverware, or ask for the check.

Left behind A guest session on table 9963.

NOT WALKABLE FROM HERE. Four of the five steps happen in a POS import queue inside the owner app, behind an admin login this container does not hold. The screen exists - I cannot reach it.

The screen this journey lives on is real, but it is behind an admin login I do not have. The one diner-side step I could reach showed no option picker on the dish I opened.

• A person would need to open the POS import queue in the owner app and link a staged option group onto the dishes it belongs to.
• They can't from here: that queue sits behind an admin login this container does not hold, so four of the five steps cannot be reached at all - not even to look at their current state.
• Operator, or EMP-1: an admin-capable owner login would make the whole journey walkable.

Couldn’t check Whether linking actually fans an option group across every dish, and whether unlinking removes it again — moot until a POS system is connected on this fixture; there is no staged import to link.

what I saw · trace.zip · diner video · owner video · report

WALKED PART WAY. Got 3 of 4 steps and everything worked. Did not finish, so I will not call it green.

With the till system switched off, the menu still comes back open with all 14 items — nothing has regressed. One of the four steps was not walked.

• Asked the same public question the test asks: is the till system switched on for this restaurant? It is not — there is no entry for it at all.
• Then asked for the menu as if it were half past ten in the morning. The kitchen came back open, with 14 things on it across the courses.
• Three of the four steps came through and everything I reached worked. The fourth I did not walk, so I am not calling this a clean green.

Couldn’t check The fourth step was not walked.

what I saw · trace.zip · patron video · report

PARTLY WALKED, NOW FILMED. The one step a customer can see works. The three till-side steps have no customer-facing screen at all, so they cannot be witnessed from outside the restaurant's own systems.

Ordering here works and the diner is told so clearly. The rest of this journey is about the restaurant's till, which is not something a customer — or I — can see.

• Sat down at table 9951 as a guest. The menu had 14 things on it: 9 drinks, a starter, 3 mains, a dessert.
• Added a Canary Cola and pressed Place order $3.50. It went through, and the Ordered tab said so plainly — ORDERED, $3.50.
• Then looked for any sign the restaurant's own till had taken it. There is none: a customer is told their order was placed, and nothing more.
• Cancelled my own dish on the way out, so this walk left nothing on the table.

Couldn’t check Whether the till actually received the order, acknowledged it, and reconciled it. Those are the other three steps, and they have no screen anywhere a person can reach.

Left behind Nothing. I cancelled the dish I ordered.

what I saw · trace.zip · patron video · report

COVERAGE HOLE. The check cannot go red in dev - no fixture can distinguish hidden from not-rendered.

Correcting my own earlier mistake: the gated restaurant really does hide the service buttons while showing its menu normally, and the green is honest.

• I withdraw the green I gave this earlier. My first reading was fooled: the only restaurant with the hide-the-service-buttons setting turned on also had zero dishes on it, so "hidden by the setting" and "nothing renders at all" looked identical.
• Then I found a restaurant that has the setting on AND a real menu — Indian Aroma, 128 items — which removes the confusion.
• Walked both sides with both menus full. On the ordinary restaurant: 9 dishes and a service control offering to call staff or ask for the check. On the gated one: 20 dishes showing normally and no service handle anywhere — I swept the whole page for anything about service, waiter, check, bill or cutlery and found none.
• So the product does what it promises, and the board's green here is honest.

Couldn’t check Nothing about the product — but the check itself is hollow, and that is filed separately. It only reads a setting, never looks at a screen, and it points at the empty restaurant, so nothing anywhere actually proves a diner's button is hidden. A warning for whoever writes that check: this control still reports itself as visible when it is invisible, because the bar collapses instead of disappearing. Count it; don't ask whether it is visible.

Left behind Not recorded in this row.

what I saw · trace.zip · patron video · report

Everything the app reports about a diner is stamped with the right table, several diners at one table stay one table, and leaving the table out of the link gets an honest 'unknown' rather than a guess.

• Sat down at table 9954 and watched what the app quietly reports back while a diner uses it.
• Every single thing it sent - the menu opening, how fast it loaded, another diner joining, page speed - carried table 9954 on it. Not one of them: all of them.
• A second guest joined the same table and got their own separate session, but the same table number. So several people at one table are recorded as one table.
• Then I opened the menu with the table left out of the link entirely. It reported the table as unknown rather than inventing one, and the server still accepted both reports without error.
• One of the reports also carried the table number a second time, as text, alongside the tidied-up number.

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

Whether anyone could reach this stays unknown, because no screen is involved in it.

• A person would need a screen to look at.
• There isn't one — every step is a direct call to the server, and no browser opens at any point.
• Nothing for me to unblock: it would take the journey itself covering a screen someone can reach.

Couldn’t check Anything a person would see. A pass here would stay a pass even if the screen behind it were unreachable.

The wine recommender answered all seven of its promises correctly, asked from inside a real diner session rather than from the outside.

• This journey has no screen of its own, so I did the next best thing: I arrived as a guest at table 9937 on the wine restaurant, which started a real diner session.
• Then, from inside the real diner page so it travelled exactly the route the app itself uses, I asked the wine recommender each of the seven things this journey promises.
• Plain scoring; that it hands back a trio to show; that asking for red ranks reds; matching a wine to particular dishes; leaving out wines that clash with a seat's allergies; and the list of things you can filter by.
• All seven held.

Couldn’t check How any of this looks to a diner. This journey has no screen of its own, so all I can say is that the answers were right.

ONLY THE BASICS. A guest reached the menu and added an item, but this journey's own steps were not walked.

The basic path — arrive, get past the entry screens, add something — works. Everything past that is still unwalked.

• Arrived as a guest and got through both of the screens that stand in the way at the start.
• Added an item to the basket. So the backbone of this journey does work.
• That is as far as it went — the proper step-by-step walk is still outstanding.

Couldn’t check Twelve of the fourteen steps. I have not looked at any of them yet.

Left behind An item is sitting in a guest basket.

RETRACTED my own finding. Re-driven answering the quiz; the helper works. STR-1195 carries the retraction and needs a HUMAN to close it - this workflow has no Won't Do transition and Done is not mine to press.

My own false alarm, withdrawn: answer the helper's three questions and it recommends the right wines at the right prices.

• Retraction — I filed a defect here in error. The wine helper is not blind to the menu.
• My earlier walk opened the cellar, saw a line saying there were no wines, and I filed it. But I had never answered the helper's three questions. That line is the placeholder shown *before* you answer, not an empty cellar.
• Re-drove it on the same restaurant and table, answering white, dry and light. The empty state goes away and the panel names exactly the two wines this menu sells, at this menu's prices. The feature works.
• The lesson for me: I called a defect from one line of text being on screen without ever supplying the input the panel needs. All the steps are stacked in the drawer at once, so "is it visible" tells you nothing — the honest test is the empty state clearing plus a real recommendation naming a priced wine.

Couldn’t check Still open and NOT part of this retraction: a report that the scoring result comes back with no serving options and no glass or bottle price, while the screen shows a glass price anyway. That was seen on another restaurant by a read-only pass, not driven by me, so it is not a claim yet.

Left behind The ticket I filed in error still needs a human to close it — this workflow has no won't-do transition, and Done is not mine to press.

what I saw · trace.zip · patron video · report

Nothing in the estate runs on the engine iPhones use, so iOS-only defects cannot be seen.

• Ran the same ordinary diner walk on webkit, firefox and chromium and compared the network, then searched the whole Jira project for any existing cross-engine coverage ticket. There is none.

what I saw · trace.zip · patron video · report

Everything a diner can SEE works on an iPhone. What fails is invisible: the app never holds a session the restaurant accepts, on every load, only on Safari's engine.

• I scanned the code at table 9994 on an iPhone 14 Pro, on the WebKit engine.
• The menu opened and offered me dishes, exactly as it should.
• I added a dish and it went into my order.
• I placed the order and the kitchen took it.
• Then I looked at what the app had actually told the restaurant about who I am — and it was holding no cookies at all, and the server had refused every call that identifies me.

Couldn’t check Whether shipping Safari.app's ITP settings match this WebKit build byte for byte — the SOP's standing position is that WebKit IS real iOS Safari, so this is recorded as an iOS finding by our own standard. Staging and prod were NOT driven; both serve the patron app from a custom domain while the API stays on a lambda-url host, so the same third-party drop is plausible there and is explicitly left open in the ticket.

Left behind One test order on the Canary Mosaic fixture, table 9994 (E2E-safe range).

what I saw · trace.zip · patron video · report

A waiter can cancel one dish out of an order but cannot serve one. The journey's whole promise - served, cancelled and still-coming showing together on the diner's phone - needs a per-dish serve, and no such control exists on the waiter's screen.

• I sat down at table 10094 as a guest and ordered four drinks - iced tea, cola, IPA, lager, $19.99.
• My phone confirmed it: all four listed as ORDERED.
• On the waiter's tablet the table showed a guest, and my order was there - one card among twenty.
• Then I tried to do what the test says a waiter does: serve one of the four dishes.
• Each dish has an X to cancel it. There is no button anywhere to serve one dish. The only serve control covers the whole order at once.
• I pressed Enter in POS to see if the serve button appears once the order moves on. Nothing changed - not on the screen, not after reloading the page.
• I checked the other two tabs of that table sheet too, since I had only looked at the first one.
• Service was empty - 'No service requests'.
• Bill showed all four drinks still reading *Order Placed*, with the app's own instruction: *'Please make sure all ordered items are moved to served state or Canceled (Remove) from the table.'* Below it, Swipe after bill is settled - greyed out.
• So the app asks the waiter to mark items served, gives no button to do it, and keeps the table locked until they do.

Couldn’t check Whether serving a dish happens on a kitchen screen I have no account for. I drove the waiter app, which is the actor this journey names, and all three tabs of its table sheet.

Left behind Live sessions and four-drink orders on tables 10091, 10092, 10093 and 10094 - three of them from runs my own harness bugs cut short. They need clearing.

what I saw · trace.zip · patron video · waiter video · report

Driven on ANANT table 10 with the real waiter daniel@, NOT the canary fixture - no canary waiter credential exists here. Grades the FEATURE.

A waiter cancels a dish and everyone is told the truth immediately - the diner sees it struck out as cancelled, the bill clears, and the table closes cleanly.

• Sat at Anant table 10 as a diner and ordered a Lassi - Mango.
• Daniel, a real waiter, opened the table on his own screen, cancelled the item and confirmed. It disappeared from his sheet along with its cancel button.
• My phone was told properly and unmistakably: the dish struck through and marked cancelled in red, with the $5.00 struck out too. Read off the screenshot, not guessed.
• Cancelling also settled the bill - the bill emptied and the close control unlocked.
• I dragged it across and the table closed back to empty.

Couldn’t check The canary's own restaurant. No waiter password we hold works there, so I did this on Anant with a real waiter instead - which grades the feature, not that particular fixture.

what I saw · trace.zip · patron video · waiter video · report

I can join a table, survive going offline, and this time staff really did close the table on me - my phone came back to a proper goodnight screen, not the menu, and even a fumbled tap on the old Add button couldn't reach it.

• I scanned in at table 10097 on Canary Mosaic, the mosaic_v2 menu rendered with 9 dishes, and I put one in my cart.
• I did what a phone in a pocket does: hid the tab and cut the network for 15 seconds. The app took it without complaint.
• This time I had Canary Mosaic's own dedicated waiter account. Signed in, opened table 10097, found the real close control on its Bill tab - a swipe, not a button - and dragged it across. The board went from "Bishop Settling - 0/1 covered" to "No guests" after a reload.
• I took my phone back out - network restored, tab foregrounded, no page reload - and instead of the menu I was looking at before, my phone showed a full-screen "Thank you / Goodnight" farewell card with a star rating and a closing line from "the chef".
• The old menu's Add buttons are still technically present underneath that screen (that is just how the DOM stacks), so as a control I tried to fumble a tap onto where one used to be. The tap timed out - the farewell screen genuinely blocks it. A person cannot reach the stale menu.

Couldn’t check Nothing this run - all five named steps plus one extra safety check (can the hidden menu underneath still be tapped?) were driven and confirmed on the real product. The unrelated STR-1209 finding from the previous attempt (Host Station ignoring ?restaurantId=) is still open separately and not re-verified here.

Left behind Table 10097 on Canary Mosaic - dev: closed, no guests, nothing owed. Table 10096 from the first re-drive attempt on this journey is also closed.

what I saw · trace.zip · patron video · waiter video · report

Close the browser entirely, come back, and your half-filled basket is still waiting. What happens after staff close the table was never reached.

• Scanned in at table 9955: 9 dishes, a live table session, and I put one dish in my basket.
• Then I shut the browser down completely - page closed, a brand new browser built from scratch - and re-opened the same QR link carrying only what the phone itself had kept.
• I came back into the same meal: same menu, same live table session, and my basket still read 1.
• That is the thing a real diner does - locks the phone, comes back later - and the product handles it.
• The other half needs staff to close the table first, and I could not do that: no owner screen closes a table session, and no staff login here reaches a canary restaurant.

Couldn’t check The negative half - that coming back is blocked once the table has been closed, and that a fresh scan starts a fresh meal. Both hang off a close I cannot perform, and those are the steps that stop a diner walking back into somebody else's finished meal.

Left behind Table 9955 has an open guest session with one un-ordered item in it, on two devices. No order was placed. I cannot close it.

what I saw · trace.zip · owner video · patron-again video · patron video · report

A diner whose phone had been asleep and offline came back and was correctly told someone else had covered his bill.

• Two diners at table 10222, both placed orders.
• Put the first diner's phone into the background and took it offline.
• The second diner then tried to pay for the whole table.
• Brought the first phone back — and it did tell him his bill had been covered.

Couldn’t check One of the thirteen steps did not complete.

Left behind Table 10222 carries the orders both diners placed, and the second diner's attempt to cover the whole table.

Whether covering someone else's bill works stays unknown, and nothing in this row says anything about the product.

• A person would need a second diner at the table to pay for someone else's order.
• They couldn't here because of me, not the app: my script never had the second diner place her own order, so the pay-for-someone screen had nothing to offer and said so.
• Unblocking is mine — re-drive it with the second diner ordering first.

Couldn’t check What the cover-someone options actually are and whether they work.

Left behind Table 10217: both of my diner sessions, with an order placed by the first and the second one's item never sent.

what I saw · trace.zip · diner-1 video · diner-2 video · report

Stopped at cover-confirm on purpose - it commits you to paying for someone else. So whether confirming notifies the covered diner is unverified by me.

Covering someone's bill works and names them correctly, but you get no confirmation, only one attempt, and the person being covered is never told any of it.

• Two diners at table 9948. The pay-for-someone-else picker works and correctly names the person you are covering.
• Choosing to cover just yourself gives no confirmation at all — the panel simply closes and nothing tells you what you just agreed to.
• You get one attempt. Ask for the check a second time and the option is gone: you are told a server is on the way, with no cover and no split offered. The same dead end turns up on the split path on a different restaurant, so it is not specific to covering.
• The person being covered is never told. Nothing on her phone mentions it, and when she asks for the check she is told nothing has been sent to the kitchen — because she has no order of her own, even though the table does.

Couldn’t check Whether confirming a cover notifies the covered diner — I stopped short of pressing confirm on purpose, because it commits you to paying for someone else. Also the waiter's covered-so-far counter: signed in as the canary owner, both fixtures show no tables assigned and no table cards, so the staff half of this journey cannot be watched here.

Left behind Table 9948: two diner sessions, with check requests made on it during the walk.

what I saw · trace.zip · patron-a video · patron-b video · report

D4 NO STAFF SCREEN
Needs a waiter or owner screen on a fixture where I have no staff account.

WALKED STEP 1 ONLY. The rest needs a staff screen I cannot reach, or an order I will not place.

Eleven of twelve steps stay unknown — and separately, this journey's own description names the wrong restaurant: it claims to reuse another one, but points at a different restaurant with a different menu and none of the same extras.

• Someone would need a waiter or owner screen for this restaurant to watch an order run through to served.
• Can't: there is no staff login for this fixture, and the admin login I hold only reaches the till-integration pages — every other admin page either refuses me or does not exist. The rest of the journey would also need a real order placed on a live fixture. I got one step in, joining the table as a diner; that is 1 of 12.
• Operator: a staff account for this restaurant.

Couldn’t check The eleven steps after joining the table. Also whether the served step is meant to be available straight after an order is entered at the till, or whether the kitchen has to act first — that is not something I can settle from the screens and the step list alone.

Left behind A guest session on this restaurant's table, from the one step I did walk.

Board says PASSED on all 11 steps. A person can walk the route, but 'Just me' bills him half the table and the receipt then tells him the table is settled when it is not.

Choosing 'Just me' does not charge you for your own items - it charges you half the whole table. I ordered $3.50, my friend ordered $7.00, and I was billed $6.86 on a receipt that then announced the table was settled when her drink was still unpaid.

• Walked the whole electronic-pay journey on its own fixture as two diners, and this time I went past the point my last walk stopped at - I actually paid, with a test card, four times over.
• The route works. You can order, ask for the check, pick how to pay, type a card in and get a receipt. Stripe really is live here, in test mode.
• But 'Just me' is not just you. The screen says you are covering your own items; what it charges is an even split of the whole table. I ordered a $3.50 drink, my friend ordered a $7.00 one, and the app took $6.86 off me - half the table plus tax and a tip - when my own drink came to $3.50.
• It is only invisible when everyone orders the same. On my earlier tables both drinks were $3.50 and $3.49, so half the table and my own share were the same to the penny. That is why my first reading of this was wrong, and I have retracted it.
• After I paid, my friend's phone asked her for the same $6.86. Between us that is $13.72 collected on an $11.44 bill.
• The receipt then says in big letters that the table is settled and there is no need to wait for the server. Her drink was not paid for. The only correction is small grey text two lines down.
• Before you pay, the check lists everything on the table without saying which items are yours, and the one number it charges you matches none of the lines. The subtotal and tax you needed in order to check it only appear afterwards, on the receipt.
• A 20% tip is already selected before you touch anything.
• And you are still asked how you want to pay before you are ever told what you owe - there is no money figure anywhere in the settle drawer.
• Three things I got wrong and am correcting out loud: the card form is not missing, you have to tap the row that says 'Card'; the tip arithmetic is fine and my own parser was broken; and I asserted two totals on a screen that does not show them.

Couldn’t check One of the eleven steps, the waiter serving the food. There is no waiter account for this restaurant - the owner login lands on a different one. And I stopped before pressing pay on my friend's phone, so I can say she is ASKED for the second half, not that it would be taken.

Left behind Tables 10090, 10094-10099 on the Canary Mosaic V2 Electronic Pay fixture: live guest sessions, placed orders, open check requests, and FOUR completed test-mode card payments (Stripe pk_test_, 4242 test card) totalling $22.86 of test money on tables 10097, 10098, 10099 and 10090. No real money moved. I have no waiter account for this fixture, so I cannot close these tables.

what I saw · trace.zip · diner-1 video · diner-2 video · report

The step this journey exists for DOES work, on the waiter's Orders tab: press Enter in POS and the order goes to the till, the card says so, and it survives a reload. But the table's own sheet - the screen a server uses standing at a table - never learns, and offers to send it again. (Corrected 2026-09-06: the earlier 'no such control exists anywhere' claim was wrong; that walk only ever searched the owner app.)

• This journey's own restaurant is empty — it says only that the menu is being prepared, with nothing on it to order. So I ran it on Canary Mosaic instead.
• On table 9951 as a guest I added a dish and pressed Place order $3.49. It went through, and I had a working cancel on it.
• Over on the owner's order board the order was there with a Confirm button. Confirming turned the card into start-preparing / mark-served / cancel.
• After that confirmation the diner still had their cancel button. That is steps 1 to 5.
• Step 6 is a waiter putting the order into the till. There is no such control anywhere. I walked all six of the restaurant's own pages plus the orders and till-settings screens, and opened the order card itself: the only actions on an order are confirm, cancel, start preparing and mark served.
• The one till-shaped thing in the whole app is a get-started button on the till settings page, which is about connecting a till in the first place, not pushing an order into one. The waiter app may well have one, but it reports no tables assigned for every test restaurant with the login I have.

Couldn’t check Steps 6 to 9: entering the till, whether cancel then disappears, whether it stays gone after a reload, and whether the kitchen screen waits on the till entry. Steps 1–5 were also walked on a restaurant that isn't till-gated at all, so 'cancel is visible before till entry' was seen where till entry never comes into play — weaker evidence than the journey intends. And this is one of four journeys that hasn't run since Sep 3 while the live ones cycle three times every 90 minutes, so its green badge is not a current result.

Left behind I cancelled my own dish, so no live order is left. Table 9951 on Canary Mosaic keeps an open guest session and one cancelled order — there is no close-table control on any owner screen.

what I saw · trace.zip · diner video · waiter video · report

An old-shaped cart left sitting on someone's phone still orders fine — the bug this journey exists to catch did not reappear.

• Joined table 10209 and added an item to the cart.
• Then deliberately mangled the cart saved on the phone, stripping out which restaurant it belongs to — that is what an old cart left over from before the change looks like — and reloaded the page.
• The solo Place Order button was still there, and tapping it worked: the order went through. The old failure this journey guards against did not come back.

Couldn’t check This row's own write-up stops mid-sentence, and one of the journey's five steps is not accounted for in it.

Left behind Table 10209: a guest session with an order placed on it.

WALKED PART WAY. Got 9 of 17 steps and everything worked. Did not finish, so I will not call it green.

Two diners at one table, each adding their own item, one order placed for both - and the waiter saw it come through. Nine of seventeen steps, all working.

• Two diners joined the same table, 9974, on the restaurant this journey has to itself.
• Each of them added a different item to the shared basket.
• The first diner placed the order for both of them.
• That restaurant's own waiter genuinely saw the order arrive.
• Everything I reached worked. I got 9 of the 17 steps and stopped there, so I will not call it green.

Couldn’t check The remaining eight steps. I did not walk them, and a green here would claim more than I checked.

Left behind An order was placed on table 9974 by the two diners I was driving.

what I saw · trace.zip · diner-1 video · diner-2 video · diner-3 video · report

WALKED STEP 1 ONLY. The rest needs a staff screen I cannot reach, or an order I will not place.

Nine of the ten steps stay unknown for want of a staff login - and the board reports this parked journey as a clean green on all ten anyway.

• A person would need a waiter or owner screen on this restaurant to watch items being served one at a time.
• There is no staff account here that reaches it. The admin credential we hold does not substitute - it is locked to the payment-till routes and refused everywhere else - and the only other way in would be placing a real order myself, which I will not do on a live restaurant.
• The operator can unblock it with a staff account for this restaurant.

Couldn’t check Nine of the ten steps: everything that happens on a waiter or owner screen. Separately, on a busy waiter order list of 20 orders my own way of picking out the right table was not precise enough to trust.

what I saw · diner video · waiter video · report

WALKED STEP 1 ONLY. The rest needs a staff screen I cannot reach, or an order I will not place.

Nine of ten steps stay unknown — and separately, the board shows this journey passing all ten steps on 50 runs in a row while its own entry says it is parked behind gates that have not shipped.

• Someone would need a waiter or owner screen to watch an order survive going offline and coming back.
• Can't: there is no staff login for this fixture, and the admin login I hold only reaches the till-integration pages. My own script also could not reliably pick one table's order out of a busy shared list, so that half could not have been scored honestly even with access. I got one step in, joining the table as a diner; that is 1 of 10.
• Operator: a staff account for this restaurant.

Couldn’t check The nine steps after joining the table, including the offline-and-recovery half, which is the part that matters. I also have no way to find out how a parked step is meant to report, so those green ticks sit oddly beside what I saw rather than proving anything either way.

Left behind A guest session on this restaurant's table, from the one step I did walk.

what I saw · diner video · waiter video

Driven on ANANT with the real waiter daniel@, NOT the canary fixture. Corrected once the diner-side settle path was driven - see STR-1202.

The waiter's own instruction says serve everything or cancel it and the table will clear, but only cancelling clears it - and serving quietly removes the cancel option too. A table where the food was served and then abandoned has no way back for staff at all.

• Did this on Anant table 2 with Daniel, a real waiter - no canary waiter password works here.
• The good part: my order reached his screen 4 seconds after I tapped, with no reload, and he can push it along until it is marked served.
• Then the dead end. The close control is greyed out and says the bill must be settled first, under an instruction telling him to move every item to served or else cancel it.
• I followed that instruction exactly - both dishes served. The instruction then vanished, so the app agrees it was satisfied. The control still never unlocked. Two full swipes did nothing.
• So I went through every control on all three tabs: there is no settle, pay or force-close anywhere in the waiter app - and the escape hatch closes behind you, because the per-item cancel button disappears once an item is served.
• Afterwards I proved the swipe itself is fine (on table 10, cancelling an item does settle the bill and the same control closes the table), and I drove the diner side and found that settling up is the diner's job and it works - so a waiter having no settle button is by design.

Couldn’t check The one possible exit I found - an unlabelled red bin control buried in the owner app, with no name on it and no entry in the manual. I reported it and deliberately did not press it. Also: a diner who has not ordered cannot ask for the check at all, so nobody can settle a bill another guest walked out on.

Left behind Anant table 2 is still sitting there with 2 guests and 2 served items on it, and no one can close it.

what I saw · diner-a video · diner-b video · waiter video

Walked end to end on a later pass: all three cooldown branches held - a fresh scan lands on the farewell screen, a dead session id cannot be resurrected, and after the window a new session is let back in. The board's green is honest here. (Corrected 2026-09-06: the older 'my run broke' summary predates that re-walk, and the stale-green note was my tooling's error, not the board's.)

• A diner and a waiter would need to walk this table through to the end together.
• My own run died before it got there — a file-writing clash with the other sessions sharing this machine, plus a bug in my own script. Both mine, not the product's. Its green badge is stale too: it hasn't run since Sep 3.
• I can unblock it myself — fix my script and re-drive when the machine is quieter.

Couldn’t check Everything past the diner joining the table.

Left behind A guest session was opened on table 9980.

what I saw · trace.zip · diner video · waiter video · report

D5 HARNESS UNRESOLVED
My own driver was wrong. My fault, not a product finding - needs a re-drive.

NOT WALKED. This one only happens after a long wait (a session going idle) and I cannot fast-forward the clock.

Whether an idle session times out and pushes the diner onto a thank-you screen stays unknown.

• A person would need to leave a table untouched for two hours and watch the session end itself.
• They can't here: that means either sitting for two real hours, or reaching behind the app to age its clock — which the automated run does from the server side and I have no way to do.
• Unblocking needs someone with server-side access to age the session.

Couldn’t check The last two steps. The menu did load and genuinely joined the table, which is as far as it got.

Left behind A joined session on table 10223.

Walked to the split panel and back out without paying. Did not settle - these are live Stripe merchants on dev.

Splitting is real and reachable, but far thinner than the name suggests: it is a headcount handed to staff, not a split bill, and no money changes hands in the app.

• Two diners at one table. Once an order is placed the settle controls really do appear — an earlier look that reported there was no split control had simply never ordered first.
• What it offers: cover someone, or split the check, and then how many ways to split it.
• That is all it is. No itemised bill, no per-person amount, no who-owes-what — it's a headcount passed to staff, and nothing in the diner app takes any money.
• Only the person who starts it sees any of this. The other diner has no settle control at all, and nothing on her phone mentions a bill.
• I threw out my own lane's headline claim before it was filed. It said the second diner can't see the table's order — but her tab starts on the just-you view and she had ordered nothing, so that reading was right for that view. Re-driven on a clean table and switched to the everyone view, she can see both orders, attributed by name, with the table total.
• Also not a fault: a split-four-ways reading at a two-person table was our own leftover from an abandoned run — though it does show the headcount counts people who are no longer there.

Couldn’t check Five of the twelve steps went unreached and the row doesn't name them. What is clear is that only the diner who starts the settle sees any of it.

Left behind Not recorded in the row. Two diners' sessions were used on the table and orders had been placed on it.

what I saw · trace.zip · patron-a video · patron-b video · report

Eighteen of twenty steps stay unknown - I walked two. (Corrected 2026-09-06: the earlier 'it has not run since Sep 3' line is WITHDRAWN. That came from my own board join, which matches suites on a name prefix that is not unique, so it read the wrong suite's history. This row's schedule was never shown to have stopped.)

• Two diners would each need to send an order, then split the bill between them.
• Can't yet, and it is my fault not the product's: only the first diner actually sent their order, so there was nothing for the app to split — and the second diner correctly saw no invite. The split sheet itself did open for the first diner.
• Me: it needs re-driving with the second diner sending too, before any of it means anything.

Couldn’t check Whether a split invite actually reaches the second diner.

Left behind Table 10225: two diner sessions, each with an item added, and an order placed by the first of them.

what I saw · trace.zip · diner-1 video · diner-2 video · report

Board says PASSED; the diner who asks to split cannot pay. Verified on two tables.

A diner who chooses to split the bill is left with no way to pay - the Check Please button greys out the moment the split is agreed, and nobody is ever told what their share costs.

• Two diners joined a table and ordered. The first asked for the check, chose to split it two ways and confirmed. The second received the invitation and accepted it.
• The first diner then reopened the service drawer - and the Check Please control is greyed out. Tapping does nothing and reloading does not help. Call Waiter and Silverware right beside it still work, so it is that one control that has been switched off.
• He chose to settle up electronically and the app took the option away. I checked both phones on tables 9973 and 9974 - the same both times.
• The second diner's invitation vanishes the instant she accepts it, and only comes back after a full page reload, where it asks her to accept the split all over again - a question she has already answered.
• Neither of them is ever told what their half comes to. It only says the table total will be split evenly, with no figure.

Couldn’t check Why the second diner's drink looks like it was never sent - her phone still offers to place that $3.49 order behind the invitation. I am reporting the screen I saw, not a cause.

Left behind Tables 9973 and 9974 are both left with orders on them and a split agreed that cannot be paid.

what I saw · trace.zip · diner-1 video · diner-2 video · report

The little view-order pill does the right thing at every stage — appearing, opening, retracting, clearing once sent, and re-arming for a second course.

• Walked the whole "view order" pill on table 10208, start to finish.
• Empty cart: no pill. Added something without sending it: the pill appears, and its caption correctly counts the items and invites you to review them.
• One tap opens the cart. Going back to the menu closes it again and the pill comes back.
• Sending to the kitchen clears the pill, and adding another item after that brings it back ready for a second course.

Couldn’t check One of the journey's eight steps is not accounted for in this row.

Left behind Table 10208: a guest session with an order sent to the kitchen and a further item added after it.

An order placed by a real diner reaches the waiter in about 11 seconds, two heat levels of the same dish stay two separate tickets, and two diners at one table are both visible.

• Signed in as the waiter and read which tables are actually his, so the board I watch is the table I order on.
• Counted his order lines BEFORE ordering, then watched for a line that was not there before - no guessed dish name involved.
• Diner one ordered at Mild: a new ticket appeared in 10.9s.
• Same dish again at Hot: a second, separate ticket in 27.8s - each line carries its own heat.
• A second diner at the same table ordered at Medium: 12.9s, and both diners were visible on one board.

Couldn’t check The 4 machine steps (token minting, fixture create/delete) have no screen. Also worth watching: the second order took 27.8s against a 30s SLO - inside it, but with 2.2s of margin on a single sample.

Left behind Nothing - both diners cancelled their own items; table 2 left as found.

what I saw · trace.zip · diner-1 video · diner-2 video · waiter video · report

The whole merchandising promise holds up end to end — recommend, price, swap glass for bottle without duplicating, order at the quoted price — but the staff side is invisible to me, and the restaurant this journey is named after sells no wine.

• Sat down as a guest at table 9946 on the wine restaurant and was offered the cellar helper. Three taps — white, dry, light — and it recommended a wine, priced by the glass at $10.00 or by the bottle at $40.00, with an alternative alongside.
• Added it by the glass: exactly $10.00 went into the cart.
• Re-took the quiz and switched the same wine to a bottle. The glass line was replaced, not duplicated — the cart settled at one line at $40.00. I proved that the careful way: waited after it looked right and read it again, because a quick check passes the instant it matches and would miss a second line landing a moment later.
• Placed the order. It went through, and the charged price matched the price the panel had quoted.
• Could not see the waiter's side of it: the waiter app would not let the canary owner in, and an earlier successful sign-in with the same account showed why it would not have helped — that board has no tables assigned to it.
• One caveat worth keeping: the restaurant named for this journey sells no wine at all and shows no cellar band on any of its courses. The wine lives on a different restaurant, which is where I walked it.

Couldn’t check The waiter's view of the pour, and two steps that have no screen at all. And I cannot tell from outside which restaurant the automated check actually drives — if it drives the one named for this journey, its cellar-band step is asserting something a guest there cannot see.

Left behind Two real unpaid orders standing on the wine restaurant, both a bottle of Canary White Wine at $40.00 — one on table 9946 from the successful walk, one on table 9942 from an earlier attempt that went through even though my own listener missed it. I cannot settle or close either; no staff account here is assigned to those tables. Also idle guest sessions on test tables 9938, 9939, 9941, 9942, 9944, 9945 and 9946.

what I saw · trace.zip · patron video · waiter video · report

An owner really can promote a dish, once you know the control lives on the dish's Menus tab. Whether promoting it changes anything a diner sees is still unproven — I would not touch a live fixture to find out.

• Signed in as the owner and went looking for the switch that pushes a dish up the list.
• Found it, but only in one place: open a dish, go to its Menus tab. There is a boost setting with four levels, from none up to high, and a chef's special switch beside it.
• Nowhere else has it — not the dish's other four tabs, not the menu builder, not Personalize, not Insights. My first, shallower look only opened the dish's default tab and would have wrongly reported that no boost control exists at all.
• Then sat down as a diner. This restaurant does show a hero carousel above every course — that is where a promoted dish would surface.
• But nothing on the menu is marked as a chef's pick, a top pick or featured. The grid is flat, so a diner is never told why a dish is being shown to him.
• I did not set or clear a boost. This restaurant runs this same journey every hour and changing it would wreck someone else's run.

Couldn’t check Whether turning the boost on makes the diner's menu change, and whether turning it off puts things back. The scoring half of this journey has no screen behind it at all.

Left behind Nothing changed — I only read the controls. An idle guest session is left on test table 9941.

what I saw · trace.zip · owner video · patron video · report

D3 WON'T MUTATE LIVE DATA
Walking it would mean creating, disabling or deleting menu items on a live restaurant.

None of the seven steps was graded, so whether a waiter's board correctly drops an abandoned table is unknown.

• A waiter would need to open their table board and see one table occupied while a stale, abandoned one is gone.
• Can't: the only staff-capable login in this container is the canary owner, and the waiter board tells it there are no tables assigned to it at all. Six of the seven steps are behind-the-scenes plumbing anyway — they mean planting a deliberately stale session on a live fixture that runs this same journey every hour.
• Operator: someone has to assign tables to a staff login, and the stale setup would still have to be planted by someone willing to write to that fixture.

Couldn’t check All seven steps.

Left behind Nothing. I signed in and looked; I planted nothing and closed nothing.

what I saw · trace.zip · waiter video · report

The rule holds and I watched it: an untagged dish reads as not-applicable and drops out when a diner asks for vegetarian, while the genuinely vegetarian dishes stay.

• On the owner's side, a dish has a dietary panel with seven diet options and ten allergen options, all there to read and set.
• Canary Grilled Chicken has no diet chosen, so it shows as not-applicable - which is exactly the rule this journey is about, visible on screen.
• Then as a diner at table 9910 I opened Mains, asked for vegetarian and applied it: 3 dishes became 2.
• The one that vanished was Canary Grilled Chicken, the untagged one. Canary Fries and Canary Margherita, both genuinely tagged vegetarian, stayed. Watched end to end.
• I went back for the vegan version of the same test and could not get there: after applying vegetarian, the filter drawer would not reopen, even after 25 seconds. I saw that once, so I am not calling it a fault.
• I also withdrew an earlier note of my own claiming Margherita had no tag - my detector was reading nothing at all, and the screenshots show it tagged. The product was right on all three dishes.

Couldn’t check The vegan half - whether a vegetarian-only dish also disappears for a vegan diner. The filter drawer would not reopen for me to change my mind. Also whether clearing every diet tag turns not-applicable back on by itself: I saw a dish already sitting in that state, I never watched it happen.

Left behind Nothing changed and nothing ordered - I opened three dish editors and never pressed Save, and never clicked a tag. Two guest table sessions left open, 9910 and 9911.

what I saw · trace.zip · owner video · patron video · owner video · patron video · report

D3 WON'T MUTATE LIVE DATA
Walking it would mean creating, disabling or deleting menu items on a live restaurant.

None of the seven steps was graded, so whether attaching a modifier actually reaches the diner is unknown — no dish on any lasting menu carries one with anything in it.

• An owner would need to attach an add-on group to a dish, take an option off it and detach it again — and a diner would need to see those changes land on the menu.
• Can't: every owner step here is a change to a shared restaurant that runs this journey live, and editing it mid-cycle would hand the builder a false red. Separately, on five of the six canary restaurants I own the owner's food-items screen does not load at all, so an owner there cannot reach the screen by any route.
• Operator: a fixture that is safe to write to, plus a fix for the food-items screen that refuses to load.

Couldn’t check All seven steps. I did establish that the owner control exists and is reachable on one restaurant; nothing beyond that.

Left behind Nothing. Read only — I opened tabs and read controls; I saved nothing and linked nothing.

what I saw · trace.zip · diner video · owner video · report

Change the quantity of a dish you already ordered and it edits the line instead of adding a second one. Watched end to end, and it is what proves the separate tile-door fault really is the tile's.

• Opened Canary Caesar Salad from its tile, stepped the quantity from 1 to 2 - the button re-priced itself to $17.98 - and added it. My order took ONE line: 2 salads, $17.98.
• Tapped that line in my order. The same dish reopened already showing 2.
• Pressed add without changing anything. My order stayed exactly as it was - one line, $17.98. So the sheet you reach from your order really is an editor, not a second add.
• That is why this row matters: it is the control that proves the edit door itself is correct, and it is cited as the falsification in STR-1212.
• I did not do the setup and teardown steps - making a dish on a live restaurant mid-run would hand the builder a false red.

Couldn’t check The signed-in diner path - I walked it as a guest. And the journey's own setup and teardown steps, which I deliberately did not run on a live restaurant.

Left behind Nothing - I emptied every basket I built and checked tables 9932, 9926 and 9931 were left empty. No order was ever sent to a kitchen. Note for the operator: table 9926 already had two other real diners on it when I arrived; I left their items alone.

what I saw · trace.zip · diner video · report

D3 WON'T MUTATE LIVE DATA
Walking it would mean creating, disabling or deleting menu items on a live restaurant.

Whether a boosted dish or a chef's special actually stands out to a diner stays unknown — and the banner that would show it only exists for a few minutes at a time.

• A diner would need to see a boosted dish and a chef's special standing out on the menu.
• Five of the six steps are the test creating those dishes and menus itself, on a live restaurant that runs this every hour — doing it myself would wreck someone else's run. And the banner only exists for the few minutes the test holds it open: I saw one at 22:39 and none at 23:16, arriving in exactly the same way.
• Needs the operator, or a restaurant that isn't live, before anyone can watch it happen.

Couldn’t check Every step of it. Anyone looking a few minutes after the test would see nothing and wrongly conclude the feature is missing.

Left behind Nothing changed and nothing ordered. An idle guest session is left on test table 9945.

what I saw · trace.zip · patron video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

All eleven steps stay unknown, because there is no build-your-own dish for a diner to open.

• A person would need to open a build-your-own main and switch between its vegan and meat options.
• They can't here: no build-your-own dish exists on any of the five test restaurants once the automated run has finished with them — I opened every dish on all five and each one offers only a photo, a price, a note box, a quantity and an add button. The owner's build-your-own switch does exist, but flipping it on a live restaurant isn't mine to do.
• Unblocking needs someone who can leave a build-your-own dish standing on a test restaurant between runs.

Couldn’t check Every step — the first six have no screen at all, and the last four need a dish that isn't there.

Left behind Nothing — read only.

what I saw · trace.zip · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Spice-Mod video · diner video · owner video · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Mosaic video · diner-Canary-Spice-Mod video · owner video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

None of the eight steps was graded, so whether diet and allergen filters correctly hide parts of a build-your-own dish is unknown.

• A diner would need a build-your-own main carrying three parts, one of them meat and one carrying an allergen, so the diet and allergen filters have something to hide.
• Can't: no such dish exists. I toured every course on five candidate restaurants and opened every dish on all of them — the menu is the same six dishes every time, and every one opens to the same plain controls. No build-your-own, no add-on group, no sides, no variants, anywhere.
• Operator or builder: a fixture with a real build-your-own dish on it.

Couldn’t check Every step. The owner-side switch and the full set of diet and allergen tags are all present and were read; only the diner half has no subject.

Left behind Nothing. Read only — no dish I opened was ever added to a cart.

what I saw · trace.zip · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Spice-Mod video · diner video · owner video · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Mosaic video · diner-Canary-Spice-Mod video · owner video · report

D3 WON'T MUTATE LIVE DATA
Walking it would mean creating, disabling or deleting menu items on a live restaurant.

Chip never renders in the stable state; proving it works needs an owner mutation I will not make on a canary fixture.

The Jain option exists for about five seconds a run and is invisible the rest of the time, so nobody can ever see it working. The filtering itself does work on the tags that stay put.

• Opened the diner's filter drawer on all four courses looking for a Jain option. It is not there - not on any course.
• The owner's side agrees: that custom tag is listed against zero dishes.
• That is because the test creates a Jain dish, checks it, and deletes it again inside about five seconds. The green is true, but only inside a window no person could ever be standing in.
• I am not calling that a lie - make it, check it, clean it up is a fair way to test. But nothing lasting shows that a custom diet tag ever reaches a diner.
• Worth knowing: this journey shares one restaurant with two others rather than having its own, and that restaurant churns while other journeys are counting dishes on it.

Couldn’t check Whether a custom diet tag actually reaches a diner. Seeing it at rest would mean creating such a dish myself on a live restaurant mid-run, which would hand the builder a false red.

what I saw · trace.zip · patron video · report

D3 WON'T MUTATE LIVE DATA
Walking it would mean creating, disabling or deleting menu items on a live restaurant.

Walked the equivalent assertions on durable dishes; the journey's own probe dishes live ~24s and were not walked.

The dietary filter really does work on the dishes that are always there. But it is a browse filter, not a safety one — dishes with no allergen data recorded slip straight through it.

• Opened the Mains course as a diner: 3 dishes.
• Tapped the vegan filter — down to 1 dish, and it was exactly Canary Fries. Tapped 'avoiding dairy' — 2 dishes. The filter genuinely filters.
• The dishes this journey creates for itself only exist for about 24 seconds before they are deleted again, so what it asserts is never visible to a person.
• Worth knowing: this is a browse filter, not a safety one. A dish with no allergen information recorded is kept by 'avoiding dairy', not hidden.

Couldn’t check The chip this journey is really about. It only appears once a matching dish exists, and the test creates that dish for a few seconds per run. Making one myself on a live restaurant mid-run would hand the builder a false red — and I no longer hold the owner login that would let me set it up.

what I saw · trace.zip · patron video · report

WALKED on Anant instead of the canary fixture. The fixture has no owner row, but that never made the BEHAVIOUR unwalkable - demo@ owns Anant, which has 32 real dishes.

A diner can say 'no gluten' and the menu really does narrow. But gluten is the only thing this restaurant lets them say — there is no way to tell it about nuts, dairy or anything else.

• Signed in as the owner of Anant and looked at what the restaurant says about its own dishes: 25 items, and the word 'allergen' appears exactly once on the whole screen.
• Sat down as a guest at table 10 and opened the dietary filter.
• It offers one choice: Gluten-Free. Nothing about nuts, dairy, shellfish, vegetarian or vegan.
• Chose Gluten-Free. The menu went from 32 dishes to 15 — so the choice really is applied, not just accepted and ignored.
• Changed nothing on the way through: I read the tags the restaurant already had.

Couldn’t check Whether the 15 dishes left are actually gluten-free, or whether the 17 that vanished were removed for containing gluten or just for having no tag at all. From the diner's side those look identical, and only one of them is safe.

Left behind Nothing. I only read; I changed no dish, tag or menu.

what I saw · trace.zip · owner video · patron video

Drink sub-categories genuinely work, just not on the restaurant this journey is about - there it is one drink and no rail, and the owner is locked out of their own menu entirely.

• On a control restaurant I watched drink sub-categories work properly: a jump rail over 9 drinks, and real dividers with headings and dish counts.
• On this journey's own restaurant there is nothing to group: Beverages is one ungrouped list holding exactly one drink, with no rail at all.
• So I went to the owner's side to look at the menu - and the owner cannot even open it. The page refuses to load their menu, and its retry button can never work.
• The food library is worse: one red line saying it could not fetch the dishes. No Add Dish button, no list, nothing. An owner cannot create the drinks, attach them to a menu, or file a sub-category.
• The board is green because this journey sets itself up behind the scenes - which is exactly the gap.

Couldn’t check This journey's own structure - the two drinks and two sub-categories it is really about. I saw the rail work on a different restaurant; I never saw this one's.

Left behind Nothing - read only. Nothing was created, changed or deleted. Two guest table sessions opened, 9941 and 9942, and nothing ordered.

what I saw · trace.zip · owner video · patron video · owner video · report

The diner really does get a sub-category strip on the menu, but the owner screens meant to create those sub-categories don't load — so I can say the strip exists and nothing more.

• Sat at table 9945 as a diner and swiped across to the mains.
• The course is not one flat list: there is a strip along the top with two tappable jump buttons, and the menu below is split into named sections with counts — one dish under sides, two under the rest. The comparison restaurant looks the same.
• The owner half is unreachable. The menu page for this restaurant fails to load and its retry button changes nothing; the food-items page is a single red error line.
• So the first three steps — create two dishes, attach them to a menu, file them under two sub-categories — cannot be done by a person on this restaurant at all.

Couldn’t check That the sections I saw ARE this journey's own two sub-categories. What shows at rest is the course's ordinary grouping; the journey's own sub-categories are not there between runs, and I could not create them because the owner screens error out.

Left behind Nothing changed. Two guest table sessions opened, on 9945 and 9946; nothing ordered.

what I saw · trace.zip · owner video · patron video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

BEING WALKED NOW on Farm + Oak, because our owner login cannot reach the Canary restaurants. This proves the FEATURE works for a real owner - it does NOT verify the canary's own fixture.

Nothing about grouping dishes by diet is known here, because the restaurant it uses has no owner to set it up as.

• A person would need to sign in as this restaurant's owner and create the dish, tag it and publish the menu - six of the eleven steps - because the five diner steps only check the effect of those.
• They can't: this restaurant has no owner at all. The setup that rebuilds it deletes its owner on every run, so there is nobody to sign in as.
• Unblocking it needs the operator to give the restaurant an owner back - a database or code change, not something I can do.

Couldn’t check All eleven steps.

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

BEING WALKED NOW on Farm + Oak, because our owner login cannot reach the Canary restaurants. This proves the FEATURE works for a real owner - it does NOT verify the canary's own fixture.

Everything this journey promises stays unknown, because the restaurant has no owner to set any of it up.

• A diner would need to see the effect of an owner creating a dish, tagging it and publishing it.
• The owner half can't be done: this restaurant has no owner attached to it at all, because the journey's own setup deletes the owner assignment every time it runs. The diner half only checks the owner half's effect, so without it there is nothing to look at.
• Needs the operator — a database change, or a backend fix so the setup stops wiping the owner.

Couldn’t check All ten steps. Blocked, not failed.

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

BEING WALKED NOW on Farm + Oak, because our owner login cannot reach the Canary restaurants. This proves the FEATURE works for a real owner - it does NOT verify the canary's own fixture.

All ten steps stay unknown — nothing about what a dish includes has been seen from a diner's side.

• A person would need an owner to set up a dish with included items, then see those on a diner's phone.
• They can't here: five of the ten steps are that owner setup and there is no owner login for this restaurant — the setup job strips the owner off it on every run. The diner half only tests the owner half's effect.
• Unblocking needs the operator: an owner account for this restaurant, or database access to attach one.

Couldn’t check All ten steps.

D3 WON'T MUTATE LIVE DATA
Walking it would mean creating, disabling or deleting menu items on a live restaurant.

Chip never renders in the stable state; proving it works needs an owner mutation I will not make on a canary fixture.

The lifestyle tag exists for about three seconds a run and is invisible the rest of the time, so nobody can see it working. Filtering itself does work on the tags that stay put.

• Opened the diner's filter drawer on all four courses looking for a Jain option. It is not there - not on any course.
• The owner's side agrees: that custom tag is listed against zero dishes.
• The reason is that the test creates a tagged dish, checks that the tiles filter down, and deletes it again inside about three seconds.
• So the green is honest about what it tested, but it happens in a window no person can reach, and nothing lasting proves a lifestyle tag ever reaches a diner.
• This journey shares one restaurant with two others rather than having its own, and that restaurant churns while other journeys are counting dishes on it.

Couldn’t check Whether a custom lifestyle tag actually reaches a diner. Seeing it at rest would mean creating such a dish myself on a live restaurant mid-run, which would hand the builder a false red.

what I saw · trace.zip · patron video · report

Add-ons stay add-ons — none of the 6 leaked onto the diner's menu as an orderable dish. The wrong-course half I could not check without creating a dish on a live menu.

• As the owner I listed this restaurant's 6 add-ons — all $2.50, all marked visible.
• Then sat down as a diner and wrote down every dish on all four courses.
• Not one of the 6 add-ons was sitting there as a dish of its own. An add-on stays an add-on.
• The other half — a dish filed under the wrong course turning up under the wrong heading — would mean creating such a dish on a live menu, so I left it alone.
• On Desserts, the one course with a single dish, there are no sub-headings at all, so there was nothing there to check a dish against.

Couldn’t check Whether a dish filed under the wrong course really does show under the wrong heading. And whether the app actually refuses to put an add-on on a menu — I only saw that none was there, not the refusal happening.

Left behind I changed nothing; one guest session was opened on table 9951. Worth flagging for the operator: this restaurant is carrying debris from earlier sessions that is not mine — 6 add-ons named UAT-modlink-optA/optB-* and a dish called 'UAT-clone-453377' that is live on the diner's Starters course.

what I saw · trace.zip · owner video · patron video · report

A diner has no way to pick between menus, and that turns out to be deliberate: a weekly schedule decides which single menu is live. The observation was right; the conclusion drawn from it would have been wrong.

• As the owner: the menu page for Canary Mosaic lists 27 menus, 25 of them switched on at the same time, and both of this journey's own two are among them. So the two-menus-at-once state really is there.
• As a diner at table 9952 I hunted for anything that picks one menu over another. There is nothing — no tabs, no dropdown, no row of chips, and none of the restaurant's menu names appears on the diner's screen at all.
• The one control that sounds like a menu picker actually holds the courses. I swiped it the way a thumb would: 9 tiles before, 9 after, nothing changed.
• Back on the owner's menu page I found the answer. Menus run on a weekly schedule — one is live now, with a time it ends and a Mon–Sun strip. '25 active' means 25 switched on, not 25 live at once. The clock picks the menu; the diner isn't meant to.
• So the missing chooser is the design, not a fault. My lane had recommended calling this a dishonest green; I overturned that and filed nothing.

Couldn’t check Steps 4 to 10. Getting one menu live and then the other on demand means editing a live schedule, which is setting things up rather than testing them. I placed no orders, so I never reached the last step — the waiter's tag showing which menu an order came from — and I make no claim about it. One caveat worth weighing: the automated run may be picking the menu through the server rather than through anything on screen. If so the promise holds, and what I've found is a capability with no human surface — a missing screen rather than a broken one.

Left behind An open guest session on table 9952. Nothing else — read only, no order placed.

what I saw · trace.zip · owner video · patron video · owner video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

None of the ten steps was graded, so whether switching modifier pricing off changes what a diner sees and pays is unknown.

• A diner would need to see a priced add-on option on a dish, watch its price disappear when the owner switches pricing off, then pick it and be charged correctly.
• Can't: no dish on any of these restaurants shows an add-on option at all, priced or not — I opened every dish on five of them and they all carry the same plain controls. The last steps would also place a real order on a live fixture.
• Operator or builder: a fixture with a dish that actually exposes a priced option.

Couldn’t check Every step. The owner's pricing switch itself is real and reachable, and the one group that exists has pricing on; I read it and did not flip it.

Left behind Nothing. Read only — no dish I opened was ever added to a cart.

what I saw · trace.zip · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Spice-Mod video · diner video · owner video · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Mosaic video · diner-Canary-Spice-Mod video · owner video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

Whether two overlapping menus price the same dish differently, and whether a diner sees the right one, stays completely unknown.

• An owner would need two overlapping menus with the same dish priced differently, and a diner would need to land on the right one.
• There is only one menu here — on all day, 14 items — and the four other candidate restaurants carry the same single menu. So there is nothing to overlap and nothing to switch between. Making a second one means changing a live menu.
• Needs the operator: a restaurant that already has two menus, or approval to create one.

Couldn’t check Every step of it.

Left behind Nothing — read only, and nothing I opened was ever added to a basket.

what I saw · trace.zip · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Spice-Mod video · diner video · owner video · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Mosaic video · diner-Canary-Spice-Mod video · owner video · report

The best thing I saw all day. The owner hides a dish and within a minute it disappears from the diner's phone on its own — and the app volunteers an apology for it. Green, and honestly so.

• As the owner I opened Food Items on Canary Mosaic, found Canary Grilled Chicken marked visible, and pressed its visibility control. The row flipped to hidden.
• On a phone at table 9934 I already had that exact dish in my cart.
• Within 60 seconds, without me touching the phone, the tile vanished by itself — 3 tiles down to 2 — while its neighbour Canary Fries stayed put.
• And the app told me unprompted that the dish was no longer available and had been taken out of my cart, offering two alternatives and a way to dismiss it.
• That is the whole journey, including the part that is easy to get wrong: the diner was told, instead of discovering an empty cart at the till.

Couldn’t check One caveat on the last step: I saw no order button with an empty cart, because the product had already taken the hidden line out. So what I proved is that a hidden dish can't be ordered because it is removed and the diner is told — not that an order button appears and sits disabled.

Left behind Nothing — put back. The dish's visibility was switched off and then on again, and the owner's row reads visible once more. The one cart line I added on table 9934 was removed by the product itself; no order was placed.

what I saw · trace.zip · owner video · patron video · report

The owner is told card payments are off while a diner on the same restaurant is offered to pay by card — and the owner has neither a route to that page nor any control on it.

• Only one of the five steps has a screen at all. I read the owner's payments page for this restaurant, and it states plainly that in-app card payments are not enabled here.
• The page does follow whichever restaurant you are on, so it is not a stub — the micro kitchen's version says something different again, about UPI and the kitchen being priced in the wrong currency.
• But on my own earlier walk on this same restaurant, the diner was offered to pay on their phone by Apple Pay, Google Pay or card. One restaurant, two screens, opposite answers, two separate walks.
• An owner has no route to that page here anyway: it is not in the sidebar. Type the address in by hand and the page carries no controls at all. A micro kitchen's sidebar does have a payments link, so the route exists for one kind of restaurant and not the other.
• An honest note on myself: my own double-check first claimed the page does *not* say payments are off. That was my mistake — I searched for a straight apostrophe and the page prints a curly one. The original reading was right.

Couldn’t check Which of the two readings is wrong. Settling it means actually pressing the pay control, and these are live payment merchants. The other four steps have no screen at all and were not graded. I also did not touch the kill switch: flipping it on a shared restaurant would hand the next run a false red.

Left behind Nothing. Nothing saved, nothing switched, nothing paid, and no table session opened.

what I saw · trace.zip · owner video · report

Ordering works here today. The half of this journey about deliberately breaking it isn't something a person can do — it's a test hook, not a feature.

• Sat down at table 9953 as a guest — nobody asked who I was.
• The menu had 14 things on it: 9 drinks, a starter, 3 mains, a dessert.
• Added a Canary Cola, pressed Place order $3.50. It went through.
• Then went looking for the owner's switch that deliberately breaks ordering — the thing this journey is really about.
• Walked all eight of this restaurant's owner pages. There is no such switch.

Couldn’t check What a diner is told when an order actually fails. I never saw the failure screen, so I can't say whether it's clear, or whether a lost confirmation quietly orders twice.

Left behind Table 9953: my guest session is still open, with two cancelled orders on it (both mine).

what I saw · trace.zip · owner video · patron video · report

D3 WON'T MUTATE LIVE DATA
Walking it would mean creating, disabling or deleting menu items on a live restaurant.

All five diner steps stay unknown, because there is no recommendation on this menu to act on.

• A person would need to open a dish, be offered something that pairs with it, and add that as its own line.
• They can't here: not one dish on this restaurant offers a pairing or an add-on. The pairings are created by the automated run and aren't left standing between runs, and making one myself means creating menu items on a live restaurant that repeats this journey hourly — a change I won't make.
• Unblocking needs someone who can leave a pairing standing on a test restaurant. One open question for the builder: the owner's side shows a pairings row on every dish while the diner sees none, and from outside I can't tell whether those rows have anything in them.

Couldn’t check Whether recommendations appear at all, and whether adding one makes its own separate cart line.

Left behind An idle guest session on table 9944.

what I saw · trace.zip · owner video · patron video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

None of the eight steps was graded, so whether the two kinds of options coexist properly for a diner is unknown.

• A diner would need one main carrying both an add-on group and a choose-one sides list, so the two sections show together and Add stays blocked until a side is picked.
• Can't: no dish combines the two. The only dish filed under sides opens as an ordinary dish, and no dish anywhere shows a sides section — so there is nothing to watch and no blocked Add button to press.
• Operator or builder: a fixture with a dish that carries both.

Couldn’t check Every step. Both owner-side pieces are visible and were read — the choose-one rule and a sides section in the menu builder; only the combination is missing.

Left behind Nothing. Read only — no dish I opened was ever added to a cart.

what I saw · trace.zip · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Spice-Mod video · diner video · owner video · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Mosaic video · diner-Canary-Spice-Mod video · owner video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

Whether two spice levels of the same dish make two separate basket lines stays entirely unknown, because no dish anywhere has a spice choice to make.

• A person would need a dish with a spice setting, so the same dish can go into the basket twice at two heat levels and make two separate lines.
• There isn't one. I toured every course on all five candidate restaurants and opened every dish: not one offers a spice choice, so there is nothing to add and no second line to make.
• Unblocking it needs someone to put a dish with a spice scale on one of these restaurants.

Couldn’t check Steps 1, 2 and 4 - everything about spice levels. The one step I could reach did hold, and chasing it is what turned up the tile-doubling fault now filed as STR-1212.

Left behind Nothing - I emptied the basket I built and checked table 9947 was left empty. No order was ever placed.

what I saw · trace.zip · diner video · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Spice-Mod video · diner video · owner video · diner-Canary-Grouping-Dietary video · diner-Canary-Groupings video · diner-Canary-Includes video · diner-Canary-Mosaic-V2-Dining video · diner-Canary-Mosaic video · diner-Canary-Spice-Mod video · owner video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

BEING WALKED NOW on Farm + Oak, because our owner login cannot reach the Canary restaurants. This proves the FEATURE works for a real owner - it does NOT verify the canary's own fixture.

Whether an owner's spice or option setting ever reaches the diner stays unknown, because there is no owner to set it.

• A diner would need to see the spice level or the option an owner set on a dish.
• The owner half can't be done: this restaurant has no owner attached, because the journey's own setup deletes the owner assignment every run. The diner half only checks the owner half's effect.
• Needs the operator — a database change, or a backend fix so the setup stops wiping the owner.

Couldn’t check All four steps. Blocked, not failed.

The owner really can manage sub-categories and a diner really does see them in an order. But the reordering cannot be tested here: every course has only one sub-category, so there is nothing to drag past.

• The owner's menu builder is richer than I expected: every course has a real named sub-category row you can rename, delete, hide, see an item count on and drop dishes into, plus a button to create a new one.
• As a diner the courses really are split into named groups with counts, each with a tappable pill that jumps you to it.
• But I could not do the one thing this journey is about — dragging a sub-category into a different order. Every course has only one named sub-category, so there is nothing to drag it past.
• Making a second one would mean changing a live menu whose tests run every twenty minutes, so I left it alone.
• There is also no labelled drag handle to take hold of — just elements that happen to be draggable, which helps neither a person nor a test.

Couldn’t check The reordering itself and everything built on it — I never saw sub-categories put into a new order, never drove the two-menus-at-once precedence flip or the switcher tiles meant to show it, and never saw a diner's menu change after an owner drag. The order I wrote down is just the restaurant's normal one.

Left behind Nothing changed — nothing renamed, deleted, hidden, created or dragged. One guest session was opened on table 9972 and nothing was ordered.

what I saw · trace.zip · owner video · patron video · report

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

Nothing here is visible to a person, so whether the screen behind it is reachable at all stays unknown.

• A person would need some screen where namespaced sub-categories actually show up.
• There isn't one - all thirteen steps are direct calls to the server, and no part of the journey opens a browser.
• Nothing an operator can hand me fixes that; it would need the journey itself to gain a screen.

Couldn’t check All thirteen steps.

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

BEING WALKED NOW on Farm + Oak, because our owner login cannot reach the Canary restaurants. This proves the FEATURE works for a real owner - it does NOT verify the canary's own fixture.

Thirteen of the fourteen steps stay unknown, and the one accusation made about this row was wrong and has been withdrawn.

• A person would need to walk the owner's menu screens on Canary Kitchen — the restaurant this journey actually names.
• They haven't yet: my map pointed at a similarly-named restaurant instead, where the owner was correctly refused entry, and I withdrew the false-green accusation built on that. That refusal was correct - the owner genuinely is not assigned there. The restaurant this journey is actually about, Canary Kitchen, is a separate problem: its setup job strips the owner off on every run, so no owner login reaches it either.
• Unblocking needs a re-drive against Canary Kitchen, and the operator to attach an owner where one is missing.

Couldn’t check Steps 4-14: create/publish a menu+item+addon+side and the patron seeing them. Mutating Canary Kitchen mid-cycle would corrupt the fixture every other hourly canary journey in this ledger depends on.

what I saw · trace.zip · owner video · report

Read the panel end to end; proving a bulk mode APPLIES needs a mutation across every dish on a canary fixture.

The bulk panel is powerful — thirteen actions across all 22 dishes at once, with a proper delete warning — but the owner's own in-product manual does not mention it at all.

• Opened the owner's food library and worked through the bulk panel, without pressing anything that commits.
• One click on select-all picks every dish — all 22 of them.
• The panel offers thirteen things you can do to all of them at once: assign, remove, boost, special, availability, spice, spice modifier, spice requirement, dietary, raw category, grouping, remove grouping and delete — all committed by a single apply button.
• In delete mode that button names the count it will delete and the panel warns the action cannot be undone. So there is no missing-confirmation problem here.
• The problem is the manual. The owner's own in-product handbook never uses the word bulk — not once in all 31,812 characters of it, with every tab clicked and every section forced open.

Couldn’t check Whether any of the thirteen modes actually work. I never pressed apply — proving one would change every dish on a shared restaurant. This also needs re-driving against Canary Kitchen.

Left behind Nothing. Read only — I selected and read; I pressed nothing that commits.

what I saw · trace.zip · owner video · report

The board called three owner features broken while an owner can plainly do all three on screen today. It has since flipped itself green.

• Signed in as the owner and opened Canary Caesar Salad. All three of the things the board says are broken are sitting right there on screen.
• The dish has a modifiers tab and a pairings tab among its five, and each explains itself in plain English - modifiers are the choices a diner picks from, pairings are only suggestions that never change the price.
• There is a pricing switch on modifiers and none on pairings, which matches exactly what pairings says about itself.
• So the red does not describe an owner's experience. One lead, offered as a lead and not a cause: the dish the test names no longer exists - open its link and you land on the food library with no editor at all. Why the test was red is the builder's to work out; I have no source.
• The board has since corrected itself and now reports this passing. My grading stands as the record of the window when it was wrong.

Couldn’t check Whether the pricing switch stays flipped. Three of the eight steps are about it persisting, and flipping it would have changed a live restaurant mid-run.

what I saw · trace.zip · owner video · report

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

Whether anyone could reach this stays unknown, because there is no screen behind it.

• A person would need a screen to look at.
• There isn't one — this journey is entirely direct calls to the server; its own description says so, and no browser opens.
• Nothing for me to unblock: it would take the journey itself covering a screen someone can reach.

Couldn’t check Anything a person would see. This would pass just the same if the screen behind it were unreachable.

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKABLE BY A PERSON. This journey's steps are direct API calls with no screen behind them, so there is nothing to look at.

All seven steps stay unknown from a person's point of view — a green here can't tell you whether the screen behind it is even reachable.

• A person would need to watch the table-session protections behave on a screen.
• They can't: by its own description this journey never opens a browser — every step is a direct call to the server, so there is nothing for a person to look at.
• Unblocking needs the journey itself to grow a screen-level check; there is nothing I can do from outside.

Couldn’t check All seven steps.

Not a canary journey - found by driving the product and comparing it to the board.

The owner's cocktail bartender page is a crash message and nothing else — and nothing on the board is red, because nothing on the board is looking at it.

• Opened the owner's cocktail bartender page. It does load — the app frame paints, six menu items down the side.
• And then the entire body of the page is a raw programmer's crash message, shown to the owner as the page's content.
• There is not one button, link or field on it. Nothing to do at all.
• No automated journey covers this page. The bar-tender journey is the diner's side of it — the cocktail banner — not this screen.

Couldn’t check What this page is meant to do. There is nothing on it to try.

what I saw · trace.zip · owner video · report

Not a canary journey - found by driving the product and comparing it to the board.

Three owner settings screens work fine, but there is no link to any of them anywhere - 77 links across six screens and not one leads there. No canary journey covers this at all.

• Three owner settings screens - payments, till and dietary - open perfectly well if you type their address in by hand.
• So I went hunting for the way in. I opened six owner screens, including the user menu and the mobile menu on each, and collected all 77 links on them.
• Not one of those 77 goes to any of the three. There is no settings link anywhere in the owner app at all.
• And the settings address on its own does not even give you a proper not-found page - it gives you a raw server error page.
• By the owner manual's own rule, something a person cannot reach in the app is not a feature.

what I saw · trace.zip · owner video · report

A micro kitchen and an ordinary restaurant open identically. Green, and it matches what I saw.

• Opened the micro-kitchen menu, and in a second fresh browser opened an ordinary full-service restaurant beside it as a comparison.
• Both arrived the same way — a dietary question first — and both menus were usable straight away.

Couldn’t check The row's own note about the menu data underneath is cut off mid-sentence, so I can't repeat what it found there.

The Collection settings page is there, opens on the right restaurant, and shows the windows that are configured.

• Signed in as the shared canary owner and opened the Micro-Kitchen dashboard.
• There is a Collection link in the sidebar. Clicked it.
• The page opened on the same restaurant I was already in, and showed the collection windows that are set up.
• Nothing was flagged as unsaved when I arrived — the page was clean.

Walked the reachable half of a red the board already reports; step 05 is behind a diner-account gate.

A delivery kitchen's order records a table number instead of an address. I saw that twice from the outside; the fulfilment questions themselves sit behind a sign-in I cannot get through.

• Arrived at the delivery micro kitchen as a diner: 9 dishes, added one, opened the basket.
• There is no pickup-or-delivery choice and no address box anywhere before you sign in. Pressing Place order stops you at a gate that tells you signing in is the first of three steps - so the fulfilment questions are the other two, behind it.
• I tried the diner account we hold, once. It was refused. I stopped rather than risk locking out a real person's account.
• On the owner's side I opened the only order this kitchen has - cancelled, $3.81, 21 hours old. It carries no address at all: the only location on it is table 10075, a table number, on a kitchen whose whole point is that there are no tables.
• I did the whole diner half again after the board flipped this journey from failing to passing. Identical: fresh table 10471, still no choice, still no address, still the same gate.

Couldn’t check Whether a pickup-or-delivery choice and an address box appear once you are signed in. The account we hold is refused at the gate, so those two steps stay unwalked and I claim nothing about them either way.

Left behind Nothing ordered - every attempt stopped at the sign-in gate.

what I saw · trace.zip · owner video · patron video · report

D5 HARNESS UNRESOLVED
My own driver was wrong. My fault, not a product finding - needs a re-drive.

NOT WALKED PROPERLY. My test order used a fake address, so 'no distance' was the correct answer. Needs a re-run with a real street address.

Whether the delivery distance and arrival time really appear stays unknown, because my own run never tested it.

• A person would need to place a delivery order and see the distance and arrival time on the owner's card.
• My own run placed it to the address the app pre-fills — a made-up placeholder no map can find — so showing no distance was the correct answer. We first called that a false green; that is withdrawn, it was my fault, not the product's. Its green badge is stale too: it hasn't run since Sep 3.
• I can unblock this myself — re-drive it with a genuine street address.

Couldn’t check Everything this journey asserts. Nothing here is graded until it is driven again.

A kitchen with no address doesn't break its order board — no gibberish distances, and no distance shown where there's nothing to measure. Green, and honestly so.

• Opened the order board for the micro kitchen — the one that carries no street address — as the shared owner.
• The board loaded without error.
• Looked all over it for broken distance or time-away text, the gibberish you get when there is no address to work from. There was none.
• And no distance appeared beside a pickup order, which is right when there is nothing to measure from.

D1 NO SCREEN
Every step is a direct API call. There is no screen for a person to look at.

NOT WALKED. I could not find a page for this. There may not be one.

None of the six steps was graded, so nothing about the mobile owner app's orders is known.

• Someone would need to open the separate mobile owner app and work an order through it.
• Can't: no web address for that app was ever given to me. It is its own app with its own hosting, dev only, and it is not one of the three apps I do have addresses for — and this container has no product source to look one up in. Its steps are direct calls in any case, so there would be no screen to look at.
• Operator: supply the address for the mobile owner app.

Couldn’t check All six steps.

A micro kitchen has no tables, and the app behaves like it - nothing anywhere suggests you are sharing with other diners.

• Opened a fresh guest session at the micro kitchen, table 10404, clearing the diet pop-up on the way in.
• Added an item - that worked - and opened the basket.
• Looked for any sign of other people at this table: no companion badge, no shared-table wording on the menu, and nothing in the basket saying who added what.
• Opened the service drawer: it mentions chat, and it does not offer call-staff.

Left behind One item added to the basket at table 10404.

An order twelve hours old was still on the owner's board, long past the two-hour cutoff a normal dine-in order gets. A pre-order does survive.

• Signed in as the owner and opened the order list for the micro-kitchen.
• Looked at how old the orders on the board were. The oldest one still showing was 720 minutes — twelve hours.
• A normal dine-in order gets dropped after 120 minutes, so something twelve hours old is well past that and still sitting there.

The owner's half of collection windows is real and settable. The customer's half — every date and time rule this journey is actually about — sits behind a sign-in I can't get past.

• Signed in as the owner of a micro kitchen. Its side menu carries three things an ordinary restaurant doesn't: Orders, Collection and Payments.
• Collection is a real settings screen. It sets how many days ahead people may book, the collection windows for each day, pickup or delivery, and the owner's own instructions to the customer — and it says party orders need longer notice than normal ones, 48 hours against 24.
• The live order board carried genuine collection windows on it, tagged pickup and delivery.
• Then round as a customer: I browsed 9 dishes and put one in the basket with no account.
• Place order stopped me. It asks who you are first, and nothing about pickup or a collection time is offered anywhere before that. The login this container holds was refused, and making a new account ends in a code emailed to an inbox I don't have.

Couldn’t check Six of the seven steps: the 24-hour floor on a normal order, the 48-hour one on a party order, whether the party floor really lands later, whether empty or too-early dates are kept out, whether the owner's instructions reach the customer, and whether anything past the booking limit is offered. The owner's wording says 48 against 24, but I never saw the two worked out for real.

Left behind Nothing — nothing saved on the owner side, no order placed, and a micro kitchen has no tables.

what I saw · trace.zip · owner video · patron video · report

The micro-kitchen owner gets an order dashboard and no table screens, and accepting a real pending order on it worked.

• Signed in as the shared canary owner on the Micro-Kitchen dashboard.
• The sidebar offers Orders. It does not offer Tables or Staff.
• Typed the tables address in by hand anyway — it bounced me straight back to the order dashboard.
• The order dashboard shows at least three status lanes, and I accepted a real pending order on it.

Couldn’t check This row's own write-up stops mid-sentence at the moment I accepted the order, so what happened after that is not recorded.

Left behind A real pending order on this restaurant's dashboard, which I accepted.

WALKED, TWICE. The board is green but a person gets the wrong experience entirely - see the finding.

Nobody asks who you are until you press Place order. Then it wants email and password - and only after you sign in does it ask your name, phone and address.

• Browsed a micro kitchen as a complete stranger: 9 dishes, added one, basket showed 1, and nobody asked who I was.
• Pressed Place order at $3.50 and got a genuinely well-written stop — in the product's own words, there is no table here, so the kitchen needs a name to hand the bag to.
• My basket stayed visible beside it, held for me, with the gate promising nothing reaches the kitchen until I have signed in and picked how I want it. The basket survives the gate.
• That is where I stop, and it is our problem rather than the product's: the gate wants a diner account and the one we hold is an owner account, so it refuses us. Correctly. I tried once and stopped.
• This replaces an earlier walk of mine that claimed I was signed in while its own screenshot showed the sign-in had failed and the gate still open. Everything it judged after that point was read off the wrong screen.

Couldn’t check Step 3 of 3 - pickup vs delivery and the collection time. Reaching it means submitting name/phone/address to a live account, which I will not do unasked.

Left behind Nothing ordered - nothing goes to the kitchen until you are past the gate, and I never got past it.

what I saw · patron video · report

D2 BLOCKED ON PROVISIONING
The fixture serves a menu but has no owner row - the canary-bootstrap Lambda deletes its owner assignment on every run. Needs a DB insert or a core change. Blocked, not failed.

WALKED, TWICE. The board is green but a person gets the wrong experience entirely - see the finding.

Both kitchens look the same right up to a sign-in wall, and we have no diner account to get through it. Whether they differ on the other side, I genuinely do not know.

• Ordered from the windowless kitchen (table 10471) and from its windowed twin (10472) side by side, to see where the two differ.
• Neither basket offers anything about pickup, delivery or picking a time. Both stop dead at the same sign-in wall — which calls itself the first of three steps, so the rest may well live behind it by design.
• The two stop screens are identical apart from the ids behind the dishes.
• I could not get through it. The account we hold here is the wrong kind, so it is rejected — which is the product working correctly, not a fault.

Couldn’t check Everything behind the sign-in: whether the order places without a time window, whether the owner receives it, the earliest-time floor, and whether the windowed twin really does still demand a time. The gate itself says 'step 1 of 3', so all of that may live behind sign-in by design — I cannot say. It stays blocked until a real diner account exists.

what I saw · trace.zip · patron-windowed video · patron-windowless video · report

Browsing and filling a basket needs no account at all. Pressing Place order doesn't get you a checkout — it gets you a sign-up that ends in an emailed code, and that is as far as I could go.

• At Canary Micro Kitchen Windowless I reached the menu, opened a dish and put it in the basket with no account at all.
• Pressed Place order $3.50. It does not open a checkout — it opens a full-screen panel asking who the order is for — in the product's own words, there is no table, so the kitchen needs a name to hand the bag to.
• It offers two boxes, an email and a password. It accepted both — and then asked for a code emailed to that address.
• I have no inbox, so that is where I stopped. A real customer with an email would get through; I can't say what is on the other side.

Couldn’t check The checkout itself, never seen. So whether it promises to arrange collection, and whether confirming really places the order, are ungraded. Signing in with the account this container holds was refused earlier the same evening.

Left behind Nothing — no order placed, no account created (sign-up stopped at the emailed code), and a micro kitchen has no table session to leave open.

what I saw · trace.zip · patron video · report

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC (not a stale snapshot): the board carries 694 distinct step names and ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. The nearest-looking suite, mksg-01..06 'micro-kitchen signup gate', is a DINER signing in to place an order - a different actor, app and Cognito pool from the owner onboarding wizard on the marketing site. So nothing in the estate would go red for any of this. Found by driving the product.

The wizard works right up to the emailed 6-digit code - and that code lands in SPAM, which is where this walk stopped three times over.

• Pressed 'Start your pilot' on the home page and gave a name, an email and a password.
• It made no fuss and put me on 'What kind of establishment is this?' - it never asked me to verify anything.
• Chose Restaurant. It moved on by itself, and my name and email were already filled in at the top of the form.
• Typed in my restaurant, my phone, Boston MA, picked a cuisine, and attached a menu, a utility bill and my ID. All three came back as 'ready'.
• 'Create account & continue' went bright and I pressed it.
• A box came up: verify your email, we sent you a 6-digit code. I do not have the mailbox, so this is where I stop. I waited half an hour for someone to read me the code and nobody did.

Couldn’t check Anything past the verify-email box: Step 3, the claim reaching the admin portal, and the hand-off to the owner app. None of it has been seen.

Left behind A part-made owner account and no restaurant. Nothing was approved.

what I saw · owner video

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC (not a stale snapshot): the board carries 694 distinct step names and ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. The nearest-looking suite, mksg-01..06 'micro-kitchen signup gate', is a DINER signing in to place an order - a different actor, app and Cognito pool from the owner onboarding wizard on the marketing site. So nothing in the estate would go red for any of this. Found by driving the product.

If you arrive at the sign-up form by link instead of by the button, you get a form you can fill in completely and can never submit, and the page never tells you why.

• Went straight to the /onboarding address, the way anyone arriving from a search result or a shared link would.
• Filled in every single thing it asked me for, and attached a menu, a utility bill and my ID.
• The 'Create account & continue' button never lit up. Not once, at any point.
• Nothing on the page told me why. No red text, no message, no tooltip when I hovered the dead button.
• Looking at the top of the form, it says 'Owner name: -' and 'Owner email: -' - and there is no box anywhere to type them into.
• Tried it again typing every character by hand instead of pasting, and again on Firefox and on Safari. Dead all three times.
• No automated journey covers this page at all.

Couldn’t check Whether a real owner would ever land on that URL - a search result, a shared link or an old bookmark would all do it.

Left behind Nothing. Nothing was ever submitted.

what I saw · owner video

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC (not a stale snapshot): the board carries 694 distinct step names and ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. The nearest-looking suite, mksg-01..06 'micro-kitchen signup gate', is a DINER signing in to place an order - a different actor, app and Cognito pool from the owner onboarding wizard on the marketing site. So nothing in the estate would go red for any of this. Found by driving the product.

'I'll verify later' is a door that does not open - it drops you back on Step 2 and eight presses of continue never move you off it.

• Filled the whole wizard in again and submitted it, and the verify-your-email box came up as before.
• Waited 8 minutes in case someone could read me the code. Nobody could.
• The box itself offers 'I'll verify later', so I took it - that is the app telling me I can come back to it.
• It put me back on 'Tell us about your restaurant'. I pressed continue again.
• And again. Eight times. Same screen every time.
• So 'later' does not exist. Without the code from the email there is no way on.

Couldn’t check Whether the code, once entered, actually finishes the job - I have never had one.

Left behind A second part-made owner account. No restaurant, no claim.

what I saw · owner video · portal video

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC (not a stale snapshot): the board carries 694 distinct step names and ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. The nearest-looking suite, mksg-01..06 'micro-kitchen signup gate', is a DINER signing in to place an order - a different actor, app and Cognito pool from the owner onboarding wizard on the marketing site. So nothing in the estate would go red for any of this. Found by driving the product.

The wizard promises 'come back anytime' and then has no way back - Login sends you to a different app entirely and your part-finished setup is gone.

• The wizard tells me, in the margin of every screen, that my setup saves automatically and I can come back anytime.
• So I came back. Pressed Login on the landing page and signed in with the account I had just made.
• It threw me at a completely different app - the owner portal's own sign-in page, 'Welcome back'.
• Nothing about my half-finished restaurant. No way back into the wizard.
• Went to the setup address by hand instead. It had forgotten me: 'Owner name: -', and the button dead again.

Couldn’t check Whether the setup really is saved server-side and only the route back is missing, or whether nothing was saved at all.

what I saw · owner video

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC (not a stale snapshot): the board carries 694 distinct step names and ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. The nearest-looking suite, mksg-01..06 'micro-kitchen signup gate', is a DINER signing in to place an order - a different actor, app and Cognito pool from the owner onboarding wizard on the marketing site. So nothing in the estate would go red for any of this. Found by driving the product.

Choose 'Micro Kitchen' and the wizard immediately starts calling you a restaurant and asking how many tables you have - after telling you a micro kitchen has none.

• Told it I run a micro kitchen - the option it describes as a home kitchen with no dine-in tables.
• Unlike the Restaurant card, this one did not move on by itself. I had to press Continue.
• The next page asks me to 'Tell us about your restaurant' and wants my 'Restaurant name'.
• And it asks how many tables I have, having just been told I have none.

Couldn’t check Whether anything downstream of Step 2 differs between the two branches - the code gate stops both at the same place.

what I saw · owner video

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC (not a stale snapshot): the board carries 694 distinct step names and ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. The nearest-looking suite, mksg-01..06 'micro-kitchen signup gate', is a DINER signing in to place an order - a different actor, app and Cognito pool from the owner onboarding wizard on the marketing site. So nothing in the estate would go red for any of this. Found by driving the product.

The Location suggestions are a fixed list of 16 US cities that never responds to what you type.

• Started typing my city into Location and a list dropped down.
• It offered New York, Los Angeles, Chicago... the same sixteen no matter what I typed.
• Typed more letters. Same sixteen.
• I can type my own city instead and it takes it - so the list is decoration, and for anyone outside those sixteen it is decoration that never matches.

Couldn’t check Whether the location is used for anything downstream - the code gate stops the walk before I could see.

what I saw · owner video

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC (not a stale snapshot): the board carries 694 distinct step names and ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. The nearest-looking suite, mksg-01..06 'micro-kitchen signup gate', is a DINER signing in to place an order - a different actor, app and Cognito pool from the owner onboarding wizard on the marketing site. So nothing in the estate would go red for any of this. Found by driving the product.

I never got into the admin portal, so the claim half of this flow is unverified. My harness, not the product - and no claim existed to find anyway.

• Opened the admin portal. It asks for a password and nothing else - no email.
• Typed the password in. The Sign In button stayed grey.
• Tried again a different way. Same.
• So I never saw the claims queue. I am not going to guess what is in it.
• In any case no claim was ever filed - the wizard never got past the email code - so the queue would have been empty of mine.

Couldn’t check Everything portal-side: whether a claim arrives, how a reviewer sees it, and what approval does.

what I saw · portal video

Not a canary journey. Confirmed against a LIVE board fetch on 2026-09-06 11:16 UTC: 694 distinct step names, ZERO matches for wizard, onboard, landing, pilot, claim, signup, register or portal. Nothing in the estate would go red for this.

Miss the emailed code and your email address is spent for good: the wizard makes you re-enter everything before refusing it, then sends you to a login that says your correct password is wrong, and nothing anywhere offers to verify the account.

• Came back to sign up again with the address I had used earlier but never verified.
• It took my name, email and password without a word of complaint and moved me on.
• So I filled the whole form in again - phone, restaurant, city, cuisine - and attached my menu, my utility bill and my ID for a second time.
• Only then does it tell me: 'This account already exists. Please log in to continue.'
• I press its own 'Go to login' button. It throws me out of the site and onto the owner app's sign-in page.
• I sign in with exactly the password I just typed twice. It says 'Incorrect username or password.' That is not true - the password is right.
• Nothing anywhere offers to resend my code or finish verifying. I looked at every button and every line of text.
• I go back to the setup page. Same banner. There is no way in and no way out. That email address is finished.

Couldn’t check Whether a support agent could rescue the account from the back end. I have no such access.

Left behind The account atish@qrate-ai.com exists in the owner pool, unconfirmed and unusable.

what I saw · owner video