Rig-scoped work is too easy to create in the wrong bead store from city/HQ context

[odcpw]

Summary

In a city that uses HQ orchestration plus one or more product rigs, it is too easy to create actionable product work in the city bead store and then route it into rig-bound work. The docs explain the distinction, but the failure mode is subtle enough that it looks like agent confusion or stalled routing rather than a bead-store mistake.

Problem

We ran a live city with:

• mayor as HQ/orchestration
• planner and reviewer working against a product rig
• a custom implementation lane

We initially created a real product initiative as a city/HQ bead. Planner/reviewer/product work naturally lived in the rig bead store, so handoffs degraded into confusing “stuck” behavior until we manually recreated the work in the rig bead store.

The docs are technically correct, but the operator experience is still easy to get wrong.

Expected

One or more of:

• stronger guardrails when city/HQ beads are routed into rig-bound workflows
• clearer diagnostics in gc sling / related commands when the wrong bead store is involved
• a first-class documented pattern for “HQ pointer/meta bead + rig-local actionable beads”

Actual

The workflow can look valid at first and then degrade into confusing handoff failures:

• planner/reviewer appear stalled
• routed work exists but is invisible from the wrong bead store
• operators end up duplicating beads by hand to recover

Reproduction

1. Start a city with HQ orchestration and a product rig.
2. Create a real product initiative bead from city root.
3. Route planner/reviewer/product work that naturally executes in the rig.
4. Observe that the rig-local agents do not naturally progress against the city-level bead, even though the operator intent is obvious.

Evidence

• Upstream docs in cmd/gc/skills/rigs.md correctly say each rig has its own .beads store.
• Upstream docs in cmd/gc/skills/dispatch.md correctly imply that rig-local work should live in the rig DB.
• In practice, the failure mode still reads like “agent got confused” rather than “wrong bead DB”.

What Was Local vs Upstream

Local/custom:

• we had a custom implementation lane

Upstream-worthy:

• the city/HQ vs rig-local bead-store UX/guardrail problem exists independently of our custom worker

Proposal

• Add an explicit HQ-to-rig workflow pattern to the docs.
• Add a clearer diagnostic when a city-root bead is being used as actionable product work for a rig-local lane.
• Consider a guardrail or suggestion that nudges the operator toward creating a rig-local actionable bead instead of routing the HQ bead directly.

Context

• Gas City version: 0.13.5
• Commit: 00a8c423
• Environment: Linux, multi-host setup with a separate worker backend

[rileywhite]

We observed the cross-rig guard working while testing a related fix (#491) — gc sling correctly blocked a city-prefixed bead targeting a rig agent. So that path is covered. The gap is when work reaches rig agents without going through gc sling, which is what this issue describes.

We looked at whether a diagnostic at bd create time could catch this earlier, but it's hard to distinguish "legitimate city bead" from "bead that should be in a rig store" without a judgment call — no clean mechanical signal at creation time.

Don't have a concrete fix to propose, but wanted to confirm the guard exists for the gc sling path and that the remaining gap (non-sling routing) seems real. Would be interested to hear if there's a direction a maintainer would prefer — happy to pick it up if so.

[rileywhite]

Field evidence: Mayor dispatch creates beads in the wrong store

Hit this today during normal gc-contrib workflow (0.13.5, 561881c).

What happened

Mayor agent sits at city root, runs bd create per the dispatch instructions, which land beads in the city store (prefix gc-). gc sling gascity/polecat gc-jtjm fires the cross-rig guard. --force bypasses the guard but fails silently because the internal bd update runs against the rig store where the bead doesn't exist (#200).

The failure mode is exactly what this issue describes: it looks like "agent got confused" or "routing is stuck" rather than "wrong bead DB."

Contributing factors

The gc-contrib Mayor context has a directory guidelines table that says:

| /home/riley/gcity | gc mail, coordination commands, bd |

This explicitly directs the Mayor to run bd from city root for all operations. For rig-targeted work, this creates beads in the wrong store by design.

Workaround used

Created the bead from the rig directory instead:

cd /home/riley/Documents/GitHub/gascity
bd create --title="..." --type=bug --priority=2
# ✓ Created issue: ga-1qn (rig prefix)
gc sling gascity/polecat ga-1qn  # works

Observation on the "no clean mechanical signal" gap

From the earlier comment — agree there's no good signal at bd create time. But gc sling does know both the bead prefix and the target rig prefix at routing time. If gc sling emitted a diagnostic like "bead gc-jtjm is in the city store but target gascity/polecat uses the ga store — create the bead from the rig directory instead" that would have saved ~15 minutes of debugging.