リリース後テストの表でコード表記の中の | がセルを割り、sprint-close が合格と読まずに理由も示さない → 書く側でエスケープし、読む側は割れた行を名指しする #1985

何を見つけたか

リリース後テストのコメントの表で、コード表記（`）の中に書いた | がセルの区切りになり、sprint-close.py --with-verification が 結果 の列を読み違えて合格と読まない。

GFM の表では、コード表記の中の | もエスケープ（\|）しなければセルを割る。読む側の sprint-close.py は lib/md.py（GFM）で表を読み、欠けたセルを空として扱う（sprint-close.py:104 の説明）。そのため行の列がずれると、結果 のセルは「合格」で始まらず、その条件は合格の行が無いものとして課題を閉じない（kept_open）。どの行の列の数が合わないかは出力に出ないため、原因が分からない。

リリース後テストを書くのは LLM（release-verification の worker）で、コマンドの引用（a | b・||）を表の中に書くことがよくある。

どこで見つけたか

スプリント m1953 の仕上げで、前のスプリントの古いリリース後テストのコメント（release PR 1933・1955・1965 のいずれか）を sprint-close.py に読ませたとき、worker が報告した。振り返りの時点ではコメントが書き直されており、2026-10-13 の今の 3 つのコメントには列の数の合わない行は無かった（再確認できたのは「今は読める」ことだけ）。

直す候補

• 書く側: release-verification の表を組み立てるとき、セルを lib/mdtable.py の cell_text（| を \| へ直す）で通す。手で書く場合の注意を手順へ足す
• 読む側: sprint-close.py が、列の数がヘッダと合わない行を「読めない行」として行番号つきで報告する（合格でない理由と区別する）

受け入れ条件

• 1. コード表記の中に | を含むリリース後テストの行を、書く側の手順で書くと、sprint-close.py が合格と読める
• 2. 列の数の合わない行があるとき、sprint-close.py がその行を名指しして知らせる
• 3. 1・2 のテストがある

関連

• 由来: PR Release: ndf v10.17.74 #1975（スプリント m1953 の仕上げ）
• 関係: 配布の記録とリリース後テストの記録を、sprint-close が読む形で書く側が書く #1870（記録を sprint-close が読む形で書く側が書く）