[yummybomb]

Summary

Adds five public page tools for the Vivid Seats marketplace:

• search_events: bounded event search by text, place, date, venue, performer, category and index-price ceiling.
• get_ticket_offers: quantity-eligible ticket listings, cheapest all-in USD prices first, price filters and zone/section grouping.
• get_event: exact public event details, stated local date/time, lineup, seat restrictions and venue address.
• get_venue: exact venue address, coordinates, time zone and catalog capacity.
• prepare_ticket_selection: re-read an exact event/listing/quantity, reject changed prices or session price groups, and return a quote and ordinary event-page handoff. Never select on the site, open checkout, reserve inventory or pay.

All are self-contained kind: page tools, restricted to www.vividseats.com, using only same-origin public GET reads. No navigation, account access, cart/checkout request, automatic write or fake confirmation framework. Preparation rejects extra inputs such as confirmed=true. Included fee components and VAT are event-specific; estimated total is not a final checkout amount. Seat numbers are not available in the listing feed.

Early-session behavior

For the first few minutes of a browser session, Vivid Seats' API proxy answers every search and listings request with a generic 404, the same answer it gives for an unknown event.

• get_ticket_offers checks the server-rendered event page once: an unknown production_id redirects to /404 and is not_found at once. A real event's listings are read again for up to 45 seconds, counting the requests' own time and bounding each request at 8 seconds so the call stays under the 60-second invocation limit, then not_ready, which says to stop after three in a row.
• prepare_ticket_selection reports that 404 as listings not served yet, pointing at get_ticket_offers, not as a missing listing. An event page that redirects, as an unknown event does to /404, is not_found; the redirect is not followed.
• search_events falls back to the site's own search or performer page for a first-page, date-sorted text search without a place. It returns site_error instead of results when that page cannot apply a requested date, category, performer, venue or price filter; only the default parking exclusion is reported as a warning. When that page holds fewer events than page_size (a performer page holds 25), its count becomes the response's page_size, and the warning names the page 2 call that continues it: the same text search with exclude_parking: false after the search page (that page is the JSON search by date without the parking exclusion), or performer_id without the text after a performer page, since a performer page lists that performer's events rather than the text search's.

Safety / limitations

Checkout transitions may hold inventory. The runtime does not enforce a trusted exact-action approval path, so hold, checkout, purchase, transfer and seller execution tools are deliberately absent. Restrictions and other site text are treated as data, never instructions. The search index can lag inventory; the radius is approximate and the result window is capped at 1000.

Status and evidence

• search_events: verified. Independent live QA on 2026-10-26 on the current source.
• get_event, get_venue, get_ticket_offers, prepare_ticket_selection: draft. Their source changed after independent QA (see Review fixes) and needs fresh independent QA.
• Author live check on 2026-10-22 in a Kernel browser: get_ticket_offers returned not_found for an unknown id in under a second and not_ready after 45 seconds for a real event early in the session. Early in a session, search_events for 'Hamilton' at page_size 50 returned the performer page's 25 events with page_size 25 and 32 pages (before the fix it claimed page_size 50 and 16 pages). A canceled get_ticket_offers read is now canceled, not site_error, and stops waiting at once.
• get_ticket_offers filters and sorts the listings itself; the event page does the same, filtering the listings response it already holds in the browser (its filterListings) and sorting by price by default.
• Live check on 2026-10-23: the search pages for 'comedy night' and 'halloween party' held the same events, order and total as the JSON search by date without the parking exclusion. With stubbed 1.5-second requests the listings wait used to take 61.5 seconds and now takes 42; live, an early-session not_ready came back after 42 seconds. A redirected unknown event returned not_found from prepare_ticket_selection, and search, offers and preparation succeeded end to end on a real event.
• Registry validator and node --test "tests/*.test.mjs" pass.

Only domain files, the two site-specific test files and this namespace's sorted registry entries are changed. Do not auto-merge.

Review fixes

• get_event and get_venue fetched with redirect: "error", so the /404 redirect of an unknown event or venue surfaced as site_error; it is now not_found (verified live: a redirect: "manual" fetch of an unknown event returns opaqueredirect). The three tools inline lib/vividseats-records.js instead of copying it.
• get_ticket_offers' not_ready suggests retry_after_seconds: 60 instead of 0. Live check on 2026-10-26: a fresh Kernel browser got the generic 404 at first and 200 with 810 listings about 70 seconds later.
• get_ticket_offers accepts the same two-decimal all-in price string prepare_ticket_selection does, so every offered listing can be prepared (all 810 live prices matched).
• Registry validator and the full Node suite (4,800) pass.

[yummybomb]

Pushed c03b671 and 2c7201c. For the first two to three minutes of a browser session, Vivid Seats answers its JSON search and listings requests with a generic 404. The event page's own requests get the same 404 and its listings panel shows "Sorry, there was an error". Some sessions never get listings.

• search_events: when the JSON search gives that 404, a text search reads the site's server-rendered search page instead. A performer match redirects to the performer page, which also applies the date range. Warnings name the page and any filter it did not apply.
• get_ticket_offers: repeats its read for up to 20 seconds while it gets that 404, then says to call again. The message also says the page's preview rows and "from" price are not filtered by quantity.
• Both tools stay draft.

Bench (5 pairs). Correct counts are shape-only. The real cheapest all-in price for 2 tickets at that time was $184:

• Haiku 5.5 low: 4/5 → 5/5 correct, 1:19 → 0:42 (1.9×). Reported $184 in 0/5 pairs without tools (it answered $230/$235 from the page's unfiltered preview) and in 5/5 with tools.
• GPT-6 Luna low: 3/5 → 2/5 correct, 0:29 → 0:17 (1.7×). Reported $184 in 1/5 without tools and 2/5 with tools. With tools, Luna answered null when the site served no listings, instead of an unfiltered price.

[yummybomb]

Pushed d83e223: get_ticket_offers now waits up to 45s per call, under the 60s invocation limit. If listings still haven't loaded, it returns status: "not_ready" with waited_seconds and retry_after_seconds instead of an error. A wait the caller cancels now reports canceled, which the output schema allows.

Bench (5 pairs). The real cheapest all-in price for 2 tickets was $186 during this run:

• GPT-6 Luna low: 3/5 → 4/5 correct; reported $186 in 0/5 pairs without tools ($183 or null) and 4/5 with tools. Paired 1:11 → 0:54.
• Haiku 5.5 low: 5/5 → 5/5 correct; reported $186 in 3/5 without tools and 4/5 with tools. Paired 1:04 → 1:14. One browser never got listings, and Haiku kept retrying for 8 minutes before answering from the preview ($230).