arch-init recovers state, but nothing instructs architects to SAVE state — close the durability loop
Gap
/arch-init (Spec 1134) ships identity adoption + state recovery from codev/state/<name>.md. But the skill is read-only by design, and Spec 1134 explicitly scoped out state-file creation/maintenance. Result: the recovery story assumes a state file that nothing in the shipped framework ever instructs an architect to write.
Today this works only in workspaces whose architects maintain state files by local convention. A fresh adopter's architect runs /arch-init after its first crash/restart and finds nothing to recover — the missing-file flow fires ("ask the human whether to start a fresh file") on what should have been the feature's headline moment.
Proposal
Two options (either closes the loop; the first is lighter):
- Fold a standing instruction into
/arch-init itself: after recovery, the architect maintains its state file as it works — append a dated section (current state, open loops, resume instructions) at significant checkpoints and before ending a session. One skill, self-reinforcing: every recovery re-primes the save habit.
- Companion
/arch-save skill: an explicit command that appends a dated checkpoint section to codev/state/<name>.md (identity via afx whoami, same validation rules as arch-init). Prompt-able ("save your state"), scriptable at session end.
Either way, the state-file "minimum contract" from Spec 1134 (opening role banner + dated sections; free-form otherwise) is already defined and should be referenced as the write format, so save and recover stay symmetric.
Two-tree rule applies: skill text changes land in codev-skeleton/.claude/skills/ and .claude/skills/ identically, with the same skill-text assertion test pattern established by spec-1134-arch-init-skill.test.ts.
Area: area/scaffold (shipped-skill content).
arch-init recovers state, but nothing instructs architects to SAVE state — close the durability loop
Gap
/arch-init(Spec 1134) ships identity adoption + state recovery fromcodev/state/<name>.md. But the skill is read-only by design, and Spec 1134 explicitly scoped out state-file creation/maintenance. Result: the recovery story assumes a state file that nothing in the shipped framework ever instructs an architect to write.Today this works only in workspaces whose architects maintain state files by local convention. A fresh adopter's architect runs
/arch-initafter its first crash/restart and finds nothing to recover — the missing-file flow fires ("ask the human whether to start a fresh file") on what should have been the feature's headline moment.Proposal
Two options (either closes the loop; the first is lighter):
/arch-inititself: after recovery, the architect maintains its state file as it works — append a dated section (current state, open loops, resume instructions) at significant checkpoints and before ending a session. One skill, self-reinforcing: every recovery re-primes the save habit./arch-saveskill: an explicit command that appends a dated checkpoint section tocodev/state/<name>.md(identity viaafx whoami, same validation rules as arch-init). Prompt-able ("save your state"), scriptable at session end.Either way, the state-file "minimum contract" from Spec 1134 (opening role banner + dated sections; free-form otherwise) is already defined and should be referenced as the write format, so save and recover stay symmetric.
Two-tree rule applies: skill text changes land in
codev-skeleton/.claude/skills/and.claude/skills/identically, with the same skill-text assertion test pattern established by spec-1134-arch-init-skill.test.ts.Area:
area/scaffold(shipped-skill content).