Order dispatcher uses city-scoped store for all wisp/exec operations, ignoring rig scope

[alexsiri7]

Problem

buildOrderDispatcher creates a single beads.BdStore scoped to cityPath (line 82 of cmd/gc/order_dispatch.go):

store := beads.NewBdStore(cityPath, runner)

This store is used for ALL order dispatches — both city-level and rig-scoped. As a result:

Formula orders (dispatchWisp)

• molecule.Cook() creates wisp beads in the city store with the city prefix (e.g., gc-)
• The pool label routes the wisp to a rig-scoped agent (e.g., gascity/dog)
• The rig agent's BEADS_DIR points to the rig store — child beads created during execution go into the rig store (e.g., ga-)
• The root wisp in the city store becomes an orphan that rig agents can't easily manage

Exec orders (dispatchExec)

• orderExecEnv() does not set BEADS_DIR based on a.Rig
• Scripts that call bd create discover the city .beads/ directory and create beads with the city prefix
• Rig-scoped agents querying their own store never see these beads

Observed symptoms

In a city with 3 rigs (gascity, reli, annie), each with their own .beads/dolt/ store:

• upstream-pr-maintain (exec order) created work beads with pool:gascity/polecat label in the city store (gc- prefix). Polecats with BEADS_DIR pointing to the gascity rig store never saw them.
• digest-generate (formula order dispatched to dog pool) created root wisps in city store. Dog agents created child step beads in rig store. Orphaned step beads accumulated in city store.
• ~15 orphaned digest beads and work beads accumulated over a few days of operation.

Expected behavior

• Rig-scoped formula orders (a.Rig != "") should create wisps in the rig's store
• Rig-scoped exec orders should set BEADS_DIR to the rig's .beads/ directory in the subprocess environment

Suggested fix

In dispatchOne (or dispatchWisp/dispatchExec), when a.Rig != "", resolve the rig path from the city config and use a rig-scoped store:

if a.Rig != "" {
    rigPath := resolveRigPath(cityPath, cfg, a.Rig)
    store = beads.NewBdStore(filepath.Join(rigPath, ".beads"), runner)
}

For exec orders, orderExecEnv should also set BEADS_DIR:

if a.Rig != "" {
    rigPath := resolveRigPath(cityPath, cfg, a.Rig)
    env = append(env, "BEADS_DIR="+filepath.Join(rigPath, ".beads"))
}

Files involved

• cmd/gc/order_dispatch.go — buildOrderDispatcher (line 82), dispatchWisp (line 241), dispatchExec (line 165), orderExecEnv (line 198)
• internal/citylayout/runtime.go — CityRuntimeEnv (no BEADS_DIR)

[rileywhite]

Investigation notes

I looked into this with the intent to fix. The code bug described is still present on current main (5054185):

• buildOrderDispatcher (line 85) creates a single city-scoped BdStore used for all dispatches
• dispatchWisp passes m.store (city store) to molecule.Instantiate, regardless of a.Rig
• orderExecEnv never sets BEADS_DIR for rig-scoped orders

However, PR #216 — which was opened to fix this issue — was closed without merging after the original reporter concluded the root cause was uninitialized beads in the rig, not a cross-store routing gap:

"i believe this was a silly claude fix for a not-real problem. i believe beads was not initialized in a rig so it just fell back to putting it in the city database and then 'fixing' the routing so it worked. the correct fix of just initializing beads works much better."

This creates ambiguity about whether the order dispatcher's store scoping is a real problem in practice. With properly initialized rig stores, rig-scoped agents have their own BEADS_DIR and routing metadata (gc.routed_to) handles dispatch — but the order dispatcher still creates initial wisps in the city store rather than the rig store.

This issue needs clarity on whether the order dispatcher's city-scoped store still produces orphaned beads in deployments with properly initialized rig stores, or whether #216's closure effectively resolves the practical impact. If someone can confirm they're still seeing orphaned city-prefixed wisps from rig-scoped orders, the fix described in this issue is straightforward.