Weather & Climate (Starlark host)
Deterministic HTTP workflows in a sandboxed Starlark hook.
The host.starlark.run example story: the lobby intent picker, a free-text forecast producing a 5-day report, the live trace lighting up with the real Starlark call and its replayed GETs, a climate-mode look-up, and the clean fail() path on an unknown place.
Can a Kitsoki story model a realistic repo workflow?
The handoffs between rooms, operator decisions, host calls, and replayed results.
The workflow is replayed from fixtures instead of improvised for the site.
Key beats
Every run begins here, in the story library — each card is a deterministic story graph kitsoki runs the same way every time. We'll demonstrate host.starlark.run, kitsoki's glue capability, on the Weather & Climate story.
This story takes a city and a mode, then runs ONE deterministic Starlark script that geocodes the place and fetches its dataset over ctx.http. No LLM, no hand-written Go — just a small typed glue script whose every HTTP call is captured and replayed from a cassette.
Click New session to create a fresh, independently-traced run of the story. It opens in the interactive view, where you drive the story on the left and watch its live trace on the right.
The run opens in the lobby. The room offers exactly the moves it allows: a free-text 'forecast' field and a 'climate' field — type a city into either. Nothing invalid is possible. Let's ask for a 5-day forecast for Tokyo.
The report room ran the Starlark script on enter: it geocoded 'Tokyo' to Tokyo, Japan, fetched the forecast over ctx.http, and bound the typed outputs to world keys the view renders — the resolved place, the current conditions, and the 5-day table. Every value here came from the deterministic glue, not a model.
Full recorded walkthrough (11 steps)
Beside the chat, the live timeline records every transition, world update, and host call as a structured, replayable event. This is the audit record: the report you just saw is fully accounted for here.
Here is the real host.starlark.run invocation. Expand it and its payload carries the __http_exchanges summary — each {method, url, status} GET the script made via ctx.http, replayed byte-for-byte from the cassette. The glue call and the network it rode are both in the trace, not hidden.
From the report room you can ask again — this time 'climate Oslo'. The very same script runs in its other branch: it resolves Oslo, Norway and fetches the 2023 month-by-month climate profile (mean temp + precipitation). One script, two datasets, both deterministic.
Ask for a place that doesn't exist and the script calls fail() — no place found. The on_error arc routes to the failed room with last_error set, so the failure is a first-class, traced outcome with a clear message, not a stack trace or a silent empty report.
Step back and you're in the lobby again, ready for another look-up — or quit to end the run. Each of those moves is an explicit, allowed intent, and each lands in the trace just like the look-ups did.
You've seen the full picture: one deterministic Starlark script geocoding and fetching over ctx.http, two modes (5-day forecast and 2023 climate profile), a clean fail() path on a bad place — every HTTP call captured and replayed from a cassette, every step in the live trace. No LLM, no bespoke Go: just typed glue you can audit. Hit '?' anytime to replay this tour.
