Mayor want's to fix gastown

[dtsage]

My mayor session keeps trying to scare me with "severe" errors in the gastown code and has even made local only commits for me to implement. I tried updating the original production release 1 to the latest on main a few days ago and still it wants to make changes. I have no idea what any of this means. I use gastown to great results but is it spiraling?
Doctor reports everything is good

See partial descriptions of the fixes from mayor:

54e13a50 — dogs could never finish their work
Every dog that completed a task got this when it tried to report done:
Error: gt done is for polecats only (BD_ACTOR=deacon/dogs/alpha)
The dogs escalated three separate times — alpha twice, bravo once — before this got prioritised. They were right every time, and the repeated reports were what eventually made it a P0.
The cause was in persistentPreRun, which guards gt done because that command can autosave and push, so it proves worktree ownership first. It decided whether the current command was gt done by walking the command ancestry and matching
on the name "done". But gt dog done is registered as a subcommand literally named "done" under dogCmd — so it matched on the first iteration and inherited a guard demanding BD_ACTOR of the form /polecats/. Dogs are
deacon/dogs/, so every dog failed.

40d5b186 — every sling leaked 8 orphaned database rows
A reaper scan reported 32 wisps with parent dependency records pointing at missing parents. I verified it rather than trusting it, and all four dangling parents turned out to be the formula wisps from my own four slings that session —
8 children each.
For every one of those parent IDs: absent from the rig's wisps and issues tables, absent from the town database too, bd show couldn't resolve them, and — the decisive part — dolt_history had no rows at all for them. They were never
written and later deleted; they never existed. Meanwhile the 8 child step-wisps did exist, each carrying a durable parent-child dependency row pointing at a parent that wasn't there.
gt sling was printing "✓ Formula wisp created: gfr-wisp-06y" for a record it never stored.
The cause was a single flag. bondFormulaDirect passed --ephemeral to bd mol bond, so the formula molecule wisp went to ephemeral storage and was never persisted to Dolt, while its children were written to Dolt with permanent references
to it. Dropping the flag fixed it.

47ae7b4b — witness notifications typed into your keyboard input
This is the one that corrupted your actual text. You typed a feature request and it arrived as:
▎ ...which might be a lot of data. RiSLOT_OPEN: GT_FolderSprawl_rs/scavenger completed (exit=COMPLETED) — slot available...c
The codebase already knew this mechanism garbles input; there's a comment saying concurrent nudges "interleave send-keys/Enter and produce garbled or empty input", and they'd added a cross-process flock plus an in-process lock for it.
But those only serialise nudge against nudge. Nothing serialises a nudge against a human typing, and nothing could, because your keystrokes don't pass through gt.
There was already a mail fallback, guarded by a comment reading "Nudge failed or Mayor not in tmux (e.g. ACP/Claude Code session)" — written for exactly your situation. But it only fires when the tmux path fails. Your mayor session
genuinely is a live tmux session, so the nudge "succeeded" at the tmux level and the function returned early having already corrupted your input. The safety net never ran.
The faulty assumption was that "the mayor session exists in tmux" implies "it's safe to type into it". True for an agent pane where nothing else types; false with a human at the keyboard.

d87a7261 — completed molecules left 8 junk beads in the work queue
After hq-4se made formula wisps persistent, their 8 step beads became ordinary open task beads — and closing the molecule didn't close them. I noticed because bd ready was offering "Load context and verify assignment" as available
work. That's mol-polecat-work boilerplate, not a task.
It matters more than backlog noise because the witness auto-dispatches ready backlog to idle polecats regardless of what I sling. A polecat could have been handed "Submit work and self-clean" as a standalone bead with no real work
attached.
It matters more than backlog noise because the witness auto-dispatches ready backlog to idle polecats regardless of what I sling. A polecat could have been handed "Submit work and self-clean" as a standalone bead with no real work
attached.

The two test commits
5e541307 and a8444495 are follow-ups to the --ephemeral removal: updating formula instantiation tests and deleting an assertion in sling_test.go that checked for the flag. No behaviour change.

[mvschwarz]

the keyboard one is real, we hit the exact same thing in openrig. an agent's message lands in the input box while you're halfway through a line and the enter sends both. worst version for me was an agent's "stand down, do not ship" landing on another agent's open prompt, and the enter picked "authorize publish"

on the spiraling, what fixed it for me was a rule that agents running on the tool find bugs but don't fix them. they write it up, a different agent fixes it, and the one that found it checks the fix. agents patching the tool they were running on is where my worst days came from, one test run took out 26 codex sessions at once

i'd also have it reproduce each one before anything else. i once lost about three days to agents carefully proving a bug that was never in the shipped code