GPT-5 finding
State restore uses .bak that is never created/rotated (risk of permanent state corruption)
highdata-losshigh
- skills/fork-release-tracker/SKILL.md:180-192
- skills/fork-release-tracker/SKILL.md:194-195
- skills/fork-release-tracker/SKILL.md:19-24
The recovery path depends on copying memory/topics/fork-release-state.json.bak back over the primary state file, but the docs never create or update that .bak. If jq empty fails post-write and .bak does not exist or is stale, the cp will fail and the corrupted file remains, risking permanent loss of dedup history and parent pointer.
Recommendation
- Create/rotate a backup before replacing the primary file, and validate the tmp file before mv: TMP=$(mktemp) jq ... memory/topics/fork-release-state.json > "$TMP" || { echo FORK_RELEASE_STATE_CORRUPT; rm -f "$TMP"; exit 1; } jq empty "$TMP" || { echo FORK_RELEASE_STATE_CORRUPT; rm -f "$TMP"; exit 1; } cp -f memory/topics/fork-release-state.json memory/topics/fork-release-state.json.bak || true mv -f "$TMP" memory/topics/fork-release-state.json - At bootstrap, also seed the backup: cp -f memory/topics/fork-release-state.json memory/topics/fork-release-state.json.bak - Optionally add set -euo pipefail to fail fast on errors.