何を見つけたか
release が置く「配布の記録」は、承認を得る前の値で書かれたまま更新されない。
devbasex/devbase の v3.7.0（release PR #212）で、本文の配布の記録が最後までこの形だった。
## 配布の記録
段階: 検証（検証のチャネルが無いため、`main` へのマージが本番への配布にあたる。承認待ちのため未実施）
版: 3.6.0 → 3.7.0（MINOR: …）
まとまり: PR #213 / #217 / …
その後、利用者の承認を得て main へマージし、本番への配布は完了している（fd5fa48、
2026-09-23 07:52 JST）。にもかかわらず記録は 段階: 検証 のままだった。
なぜ実害になるか
progress-tracking の「まとまりを閉じる」の閉じる条件 1 は、この行だけを読む。
| 読むもの |
読み方 |
| 条件 1 |
使う記録の 段階: の値が 本番 または 配布なし で始まる（case "$stage" in 本番*|配布なし*)） |
検証 で始まる値はどちらにも当たらないため、配布が終わっているのにまとまりの課題 8 件が
すべて 開いたまま（本番への配布の前） になる。 別のセッションから「まとまりを閉じる」を
行うと、会話の中の事実ではなく Pull Request のこの行が正になるため、誤りに気づけない。
今回は仕上げの持ち場が気づいて、更新した記録をコメントで投稿して回避した
（読む側は「最後の ## 配布の記録 ブロック 1 つだけ」を読むため、コメントで上書きできる）。
この回避は手順に書かれていない。
どこで見つけたか
release の手順は「配布の記録を置く」までを書き、承認を得て配布を実施した後に記録を
更新する段を持たない。 承認の前に本文を書く運用（Draft の時点で本文を用意する）と
組み合わさると、必ずこの食い違いが出る。
なぜこの変更の範囲外なのか
v3.7.0 の 8 課題（devbasex/devbase の #161 #160 #188 #192 #195 #203 #208 #209）は、
base イメージの描画・機密の見出し・scale の経路・文書の列挙・テストの隔離を対象にしている。
Skill の手順は対象外である。
直さないと何が起きるか
- 配布が終わったまとまりの課題が、別のセッションから閉じられなくなる。
手作業で閉じると「まとまりを閉じる」の 4 分類（閉じた / 既に閉じていた /
失敗 / 開いたまま）から外れ、reopen の手段が報告に残らない
- 配布の段階を後から読む人が、検証で止まったまとまりと、本番まで通ったまとまりを
区別できない
直し方の案
| 案 |
内容 |
| A |
release の手順に「配布を実施した直後に、実施後の値で配布の記録を更新する」段を足す。更新は本文の書き換えでも、## 配布の記録 ブロックのコメント投稿でもよい（読む側は最後の 1 つを読む） |
| B |
承認の前は配布の記録を置かず、実施後にだけ置く。段階: に「承認待ちのため未実施」の値が生まれない |
| C |
progress-tracking の読み方に「段階: が 検証 で、かつマージ済みなら止まって利用者に聞く」を足す（対症） |
A か B が修正レイヤーである。C は読む側で受け止めるだけで、記録の側の誤りは残る。
修正の場所
直す場所は #850 / #862 のスクリプトになる。
#862 の受け入れ条件は「承認前の値の記録が残らない（案 A か B）」を持つ。
関連
由来
devbasex/devbase の issue #161 / #160 / #188 / #192 / #195 / #203 / #208 / #209
（v3.7.0 のリリース後テストと振り返り、PR devbasex/devbase#212）
何を見つけたか
releaseが置く「配布の記録」は、承認を得る前の値で書かれたまま更新されない。devbasex/devbaseの v3.7.0（release PR #212）で、本文の配布の記録が最後までこの形だった。その後、利用者の承認を得て
mainへマージし、本番への配布は完了している（fd5fa48、2026-09-23 07:52 JST）。にもかかわらず記録は
段階: 検証のままだった。なぜ実害になるか
progress-trackingの「まとまりを閉じる」の閉じる条件 1 は、この行だけを読む。段階:の値が本番または配布なしで始まる（case "$stage" in 本番*|配布なし*)）検証で始まる値はどちらにも当たらないため、配布が終わっているのにまとまりの課題 8 件がすべて
開いたまま（本番への配布の前）になる。 別のセッションから「まとまりを閉じる」を行うと、会話の中の事実ではなく Pull Request のこの行が正になるため、誤りに気づけない。
今回は仕上げの持ち場が気づいて、更新した記録をコメントで投稿して回避した
（読む側は「最後の
## 配布の記録ブロック 1 つだけ」を読むため、コメントで上書きできる）。この回避は手順に書かれていない。
どこで見つけたか
devbasex/devbaseの PR Docs: issue #161 の要求仕様と設計（設計工程を規約化する Skill） #212 の本文と、そこへ投稿した更新の記録skills/release/SKILL.mdの手順 3（配布の記録を Pull Request の本文へ置く）skills/progress-tracking/SKILL.mdの「配布の記録」の読み方の表releaseの手順は「配布の記録を置く」までを書き、承認を得て配布を実施した後に記録を更新する段を持たない。 承認の前に本文を書く運用（Draft の時点で本文を用意する）と
組み合わさると、必ずこの食い違いが出る。
なぜこの変更の範囲外なのか
v3.7.0 の 8 課題（
devbasex/devbaseの #161 #160 #188 #192 #195 #203 #208 #209）は、base イメージの描画・機密の見出し・
scaleの経路・文書の列挙・テストの隔離を対象にしている。Skill の手順は対象外である。
直さないと何が起きるか
手作業で閉じると「まとまりを閉じる」の 4 分類（
閉じた/既に閉じていた/失敗/開いたまま）から外れ、reopen の手段が報告に残らない区別できない
直し方の案
releaseの手順に「配布を実施した直後に、実施後の値で配布の記録を更新する」段を足す。更新は本文の書き換えでも、## 配布の記録ブロックのコメント投稿でもよい（読む側は最後の 1 つを読む）段階:に「承認待ちのため未実施」の値が生まれないprogress-trackingの読み方に「段階:が検証で、かつマージ済みなら止まって利用者に聞く」を足す（対症）A か B が修正レイヤーである。C は読む側で受け止めるだけで、記録の側の誤りは残る。
修正の場所
直す場所は #850 / #862 のスクリプトになる。
## 配布の記録を書く側と読む側をdist-record emit/parseの 1 つの部品にする。段階:の値の語彙（承認待ちの値を作らない）はここで決まる
release.pyがdist-record emitを呼ぶ形にする。案 A（実施後に更新）か案 B（実施後にだけ置く）は、
emitを呼ぶ時点として決まる#862 の受け入れ条件は「承認前の値の記録が残らない（案 A か B）」を持つ。
関連
dist-record）release.py）由来
devbasex/devbaseの issue #161 / #160 / #188 / #192 / #195 / #203 / #208 / #209（v3.7.0 のリリース後テストと振り返り、PR devbasex/devbase#212）