prerelease tag recovery procedure

「プレリリースタグ」解釈と release 復元手順

判断

Master 発話の「プレリリースタグ」は、第一解釈として GitHub Release の prerelease フラグ (boolean 属性) を指す。git tag や release entry そのものではない。誤って release を削除した場合の復元手順を本記録に固定する。

経緯

rules/operations/operations.md の release terminology interpretation ladder で「最も保存的な解釈を優先、literal delete は最後」と既に明文化されているが、実際の対話で「プレリリースタグ」「tag を消す」のような発話が出たとき、AI が literal delete (git tag delete) に飛びつく drift が観測された。最も保存的解釈は属性変更 (prerelease → stable) であり、tag 削除は ladder の最終段階。

理由

• GitHub Release の prerelease 属性 = boolean フラグ。release entry を保ったまま gh release edit {tag} --prerelease=false で promotion できる。tag name は変えない
• 「タグ」という日本語は git tag (refs/tags) と GitHub Release tag を区別しない口語。AI 側は文脈から「flag attribute on Release」を第一候補に解釈する
• 万が一 release を消してしまった場合、git tag が local に残っていれば revert path がある

復元手順 (誤削除時)

# 1. ローカル保持の tag SHA を確認
git for-each-ref refs/tags/...

# 2. tag を origin に push (ローカルにあれば revivable)
git push origin refs/tags/...

# 3. GitHub Release を再作成 (notes は generate)
gh release create {tag} \
  --target main \
  --title {version} \
  --generate-notes \
  --latest=false

state flag は意図に応じて --prerelease / --latest=false を選択。Latest anchor は別途 gh release edit {tag} --latest=true で human が flip する (詳細: rules/operations/release-version.md Anchor flip procedure)。

含意

• Master 発話の「プレリリースタグ」は flag 操作と読む。git tag delete は ladder 最終段階で確認必須
• release 削除事故時、git tag が local に残っているうちに復元する。reflog 経由復元は最後の砦であって第一手段ではない
• canonical command (gh release create ... --generate-notes --latest=false) を毎回 literal 確認、anchor 維持を必ず優先

関連

• rules/operations/operations.md Release terminology interpretation ladder
• rules/operations/release-version.md Canonical release creation command, Anchor flip procedure

メンテナンス

この判断記録は、以下の場合に削除する:

• gh CLI / GitHub API の release / tag 挙動が根本的に変わり、本記録の手順が無効になったとき
• Master の「プレリリースタグ」用法が変わり、第一解釈が別軸になったとき
• 同種の誤解釈が 6 ヶ月以上観測されず、参照が途絶えたとき