[yummybomb]

Summary

• Add public standard-table availability and exact reservation preparation to the restaurant search/profile/review tools.
• Add dining-points and reservation/invitation count reads, plus paginated Favorites restaurant IDs, with fresh expected-account checks.
• Bound profile arrays/menu output, reject impossible timestamps and malformed dates, honor cancellation, and fail closed on unknown seating-specific experience data.
• Judge availability dates by the restaurant's calendar (its profile's UTC offset), not UTC's, so tonight stays searchable in the US evening; without the restaurant's offset, dates are judged by UTC-12. Slots the site returns outside the requested window_minutes are left out before their shape is checked, rather than failing the read.

All seven tools are page-local and registered as one namespace. get_availability and prepare_reservation share lib/opentable-availability.js; get_restaurant and get_reviews share lib/opentable-restaurant-page.js. The two account tools keep their own copies of the dashboard read so their QA'd source is unchanged. Availability replays the site's observed read-only query using the current profile credential and a dynamically extracted first-party query document ID. Module reads are bounded (a live read fetched 184 modules), and the query ID is kept in the tab's sessionStorage keyed by the entry module, which names the site's build, so later reads skip them; it is dropped when the query reports an error. Query errors fail explicitly, and credentials/slot hashes are never returned.

'Access Denied' documents

OpenTable often answers a Kernel browser's home and search pages with 'Access Denied' while still serving restaurant pages. get_restaurant, get_reviews, get_availability and prepare_reservation no longer refuse because of the current document; they judge OpenTable's actual responses. get_restaurant and get_reviews accept a restaurant's short /<name-slug> address (never account or sign-out paths). A refused search points at that address and asks to check the returned name and address before using the restaurant_id, since a short address can belong to another location. Short addresses are refused only when they name a sign-in, account or booking path, so restaurants such as /log-haven are accepted.

Safety and limitations

Preparation never selects a slot, holds inventory, books, navigates, verifies the booking account or establishes deposits/cancellation/no-show fees. It requires an exact observed standard date/time/party/seating match and returns a public profile handoff. Booking, holds, cancellation, modification and notifications remain unshipped because the runtime has no trusted exact-action human approval path. No live booking, hold, favorite or account mutation was performed.

Account summary exposes container counts only, not unobserved reservation item details. Favorites' populated ID shape is grounded in the site's query definition and covered by fabricated fixtures. Save/unsave and account changes are omitted. Bot protection and first-party bundle-format changes fail explicitly.

Status and evidence

• get_account_summary, list_saved_restaurants: qa_passed. Independent final-source QA at 93dd9c6, Node-fixture-only for account success, populated and wrong-account cases; source unchanged since.
• search_restaurants, get_restaurant, get_reviews, get_availability, prepare_reservation: draft. Their source changed after that QA for the 'Access Denied' handling, so they need fresh independent QA.
• Author live check on 2026-10-22 in a Kernel browser whose home page showed 'Access Denied': get_restaurant by short address, get_availability and prepare_reservation succeeded (prepared, no hold). With the page clock at 7pm Pacific, get_availability for a San Francisco restaurant that evening returned slots (before the fix: invalid_input), and get_restaurant with /log-haven returned that restaurant (before: invalid_input).
• Registry validator and node --test "tests/*.test.mjs" pass.

Do not auto-merge.

[yummybomb]

Pushed f4c3d6b: OpenTable often serves a Kernel browser "Access Denied" on its home page and /s search while still serving restaurant pages. The read tools refused whenever the current document was that page, and search_restaurants told the agent to wait or switch browsers, which it can't do (Luna then answered times: []).

• get_availability, get_restaurant and get_reviews no longer refuse because of the current document's title; they judge the actual response.
• get_restaurant/get_reviews accept a restaurant's short /<name-slug> address (hyphenated names only; account, sign-out and booking words are refused before any request).
• A refused search now says to call get_restaurant with that short address.
• The four changed tools are back to draft.

Bench (plain Kernel browsers, 5 pairs, paired medians over pairs where both arms were correct):

• Haiku 5.5 low: 5/5 → 5/5 correct, 1:47 → 0:17 (6.2×)
• GPT-6 Luna low: 5/5 → 4/5 correct, 0:29 → 0:15 (2.0×). The miss was a browser where OpenTable also refused the availability query, which the site's own page uses to show times.

With tools, every trial on both models reported 19:45 and 20:00. Haiku without tools listed extra times in 2 of 5 pairs, which is why the report labels this intent "mixed".