fix(mission-control): namespace the designer-rotation state key — one file was shared by every mission - #686
Merged
sunholo-voight-kampff merged 1 commit intoAug 13, 2026
Conversation
… file was shared by every mission
The skill prescribed `~/.ailang/state/mission-designer-rotation`, an UNNAMESPACED path,
so all three missions on the rig read and write one file and a sibling's designer run
silently overwrites yours. The Repo Profile's claim that "namespaced state keys (M1) keep
two missions on one rig from colliding" is true of the keys M1 covered and false of this
one — which is why nobody re-checked it.
Two first-party frictions:
1. Iteration 187 recorded advancing V1's pointer claude -> codex. Iteration 188 read
`claude:claude-fable-5` back, mtime 01:10, while V1 was idle (23:42->01:12) and
mission-world was mid-iteration with a fable designer — consistent with a sibling
write, and certain either way that 187's recorded advance was lost.
2. Iteration 188 then had to adjudicate between the state file and the mission log to
pick a designer at all, a coin-flip no rule covered.
The failure is silent and self-concealing: a clobbered pointer still holds a valid
rotation value, so the only tell is a disagreement between the file and the previous
iteration's own record — and the natural reading ("trust the state file") is the wrong one.
Measured: `~/.ailang/state/` already holds `mission-world-designer-rotation` and
`mission-motoko-designer-rotation`, namespaced files hand-created by careful sibling
controllers, that the skill's literal path never reads.
Both call sites now use `mission-${MISSION_NAME}-designer-rotation`, with a one-line
migration (seed from the unnamespaced file if the namespaced one is absent, then never
write the unnamespaced one again) and a generalisation: any `~/.ailang/state/` key this
skill names as a literal is shared by every mission, so audit the whole path list rather
than one key at a time.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
sunholo-voight-kampff
deleted the
sprint/iter188-designer-rotation-namespace
branch
August 13, 2026 00:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Gate-5 skill fix from V1 iteration 188. One file changed.
The skill prescribed
~/.ailang/state/mission-designer-rotation— unnamespaced, so all three missions on the rig read and write one file and a sibling's designer run silently overwrites yours. The Repo Profile's claim that "namespaced state keys (M1) keep two missions on one rig from colliding" is true of the keys M1 covered and false of this one.Two first-party frictions (the ≥2 bar):
claude → codex; iteration 188 readclaude:claude-fable-5back, mtime 01:10, while V1 was idle (23:42→01:12) andmission-worldwas mid-iteration with a fable designer. Consistent with a sibling write; certain either way that 187's recorded advance was lost.The failure is silent and self-concealing: a clobbered pointer still holds a valid rotation value, so the only tell is a disagreement between the file and the previous iteration's own record — and the natural reading ("trust the state file") is the wrong one.
Measured:
~/.ailang/state/already holdsmission-world-designer-rotationandmission-motoko-designer-rotation— namespaced files hand-created by careful sibling controllers — that the skill's literal path never reads.Both call sites now use
mission-${MISSION_NAME}-designer-rotation, with a one-line migration and the generalisation that any~/.ailang/state/key this skill names as a literal is shared by every mission.🤖 Generated with Claude Code