[takemi-ohama]

#2474 の設計文書と、要求・受け入れ条件のコピーを追加します。止める指示（loop stop が置くファイル）を、人がそのセッションへ送った停止からだけ置くように conductor の手順で決める設計です。loop start で止める指示を消す処理と、経過時間の計算は変えません。コードの変更は含みません。

利用者向けの変化

• 無し

移行の手順

• 無し

変更の要点

• 要求と受け入れ条件のコピー（issues/issue-2474-requirements.md ）
  • 開発ループ: 止める指示を人が送った停止だけから置く（人が送っていない文から置かれた止める指示が、再開後の境で user_stop を起こした） #2474 の本文から、要求と受け入れ条件をコピーした
• 設計文書（issues/issue-2474-design.md ）
  • 止める指示を置く場面は、人がそのセッションへ停止を送ったときだけに限る。限定は conductor の手順で決め、コマンドや hook の側で入力元を判定しない（決定 1）
  • loop start は止める指示を消さない。人が送った停止は次の周回の境で効くのが正しい振る舞いのため（決定 2）
  • 経過時間の計算は変えない。境で止まった後の区間はすでに経過時間から外れている（決定 3）
  • セッションを終える依頼を止める指示に読み替えない（決定 4）。誤って置いた止める指示は、置いた conductor だけが消す（決定 5）
  • 確定仕様の直し方は、中身の章の末尾に置いた
  • 目的の章では、条件の名前に説明を添えた
  • 根拠に挙げた Value には題を添えた
• 変更したファイルは上記の 2 件で、追加は 363 行です

テスト

検査	結果
用語集の検査	成功（終了コード 0）。設計の宣言と用語集が揃っている
要求のコピーの検査	成功（終了コード 0）。issues/issue-2474-requirements.md は #2474 の本文と一致する

モード: standard / 通した工程: 設計 → 要求と受け入れ条件 → ドキュメント再構成 → ドキュメントレビュー

🤖 Generated with Claude Code

決めたこと

issues/issue-2474-design.md

• 決定 1: 発生元の限定は conductor の手順で決め、コマンドや hook の側で入力元を判定しない
• 決定 2: loop start で止める指示を消さない
• 決定 3: 経過時間の計算を変えない
• 決定 4: セッションを終える依頼を止める指示に読み替えない
• 決定 5: 誤って置いた止める指示は、置いた conductor だけが消す

[takemi-ohama]

🤖 cross-review | round 1 | codex | APPROVE

指定範囲に critical / major の修正指摘はありません。根拠: Value 3 / Value 8。

[takemi-ohama]

🤖 cross-review | round 1 | kiro | APPROVE

ドメインモデルの節を見た。コンテキストは 1 つで関係の変更は無く、集約「開発ループ」の持ち主は 1 つ（sprint_loop.py の副命令）、不変条件 I1〜I6 は 1 行 1 条件で矛盾は無く、ドメインイベント E2・E4・E5・E6・E8 はいずれも受け手を持ち要求の番号を引き継いでいる。用語の表の 5 語（開発ループ・周回・ループの予算・止まる条件・ループの記録）は docs/glossary/glossary.json の ndf-workflow の既存の語と一致し、新しい語は足さない宣言どおり用語集の差分は無い。stops へ足す行の形（condition・values・lap・at・resumed_at）は resume_record が書く既存の行と一致し、active_seconds・failure_streak・lap_rows の各読み手への当てはまりの表もコードの読みと一致する。設計レベルの修正提案は無い。

[takemi-ohama]

🤖 cross-review | round 2 | claude | REQUEST_CHANGES

周回の途中の loop start は、利用者の再開だけでなく、カットポイントの ndf-next や利用上限でのアカウント切り替えで、ラッパーが自動に起動した次のセッションからも打たれる。このため、無条件に止める指示を消す設計は、利用者の止める指示を黙って消す。どちらの起動から来たかを区別する仕組みを設計に足す必要がある。

[takemi-ohama]

🤖 cross-review | round 2 | kiro | APPROVE

要求・設計の 2 文書を全読し、設計が依拠する既存コードの振る舞いを sprint_loop.py（cmd_start・apply_budget・resume_stopped・_resume_user_stop・resume_record）と sprint_loop_record.py（active_seconds・boundary_stop・failure_streak・lap_rows・current_lap・write_record）で突き合わせた。設計の『構成要素』『値の集合へ値を足す影響』の各表の読み（active_seconds は stops の at〜resumed_at と周回区間の重なりを引く / boundary_stop は user_stop を先に見る / lap_rows は周回ごと 1 件で後勝ち / failure_streak は same_failure だけを使う / 進行中の周回は current_lap）は実装と一致する。受け入れ条件 4・I3 の経過時間 (T1−T0)+(T3−T2) は active_seconds の重なり控除と整合し、決定 3（消してから書く・消せなければ記録を書かず終了 1）・決定 5（T1 を T2 以下に揃える、T1<T0 は _overlap が周回区間で切るため揃えない）も矛盾しない。実装者が別物を作る食い違い、利用者経路の誤動作、秘密・認可・データ・戻せない操作、トークン・時間・回数を増やす変更のいずれも、基準に当たるものは見つからなかった。設計レベルの修正提案は無い。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 2 | commit (なし)

対応件数: critical=0 / major=0 / minor=0（合計 0 件）
決着: 0 件 / 見送り: 1 件 / 却下: 0 件
CI: SUCCESS

[takemi-ohama]

🤖 cross-review | round 3 | claude | REQUEST_CHANGES

周回の途中で止まった記録（gate2_returned・refused）の再開の経路が、止める指示を解く対象から漏れている。このため #2474 と同じ症状がこの経路に残る。

[takemi-ohama]

🤖 cross-review | round 3 | codex | APPROVE

指定範囲の2ファイルを確認し、既存指摘と重複しない critical / major の修正指摘はありません。根拠: Value 3 / Value 8。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 3 | commit 4882b6e

対応件数: critical=0 / major=1 / minor=0（合計 1 件）
決着: 1 件 / 見送り: 1 件 / 却下: 0 件
CI: SUCCESS

[takemi-ohama]

🔧 /ndf:fix サマリ | commit (なし)

対応件数: critical=0 / major=0 / minor=0（合計 0 件）
決着: 0 件 / 見送り: 1 件 / 却下: 0 件
CI: NONE

[takemi-ohama]

🤖 cross-review | round 4 | codex | REQUEST_CHANGES

別のセッションからのセッション終了依頼を、人への確認待ちにする処理フローを、要求の E3 と設計の E3・F2 に合わせて修正してください。根拠: Value 2 / Value 8。

[takemi-ohama]

🤖 cross-review | round 4 | kiro | APPROVE

要求・設計の 2 文書を全読し、設計が依拠する既存コードと確定仕様で裏取りした。この版は従来の『loop start で止める指示を消す』案（round 2/3 で claude が指摘した、自動の再起動も周回の途中で loop start を打つため人の停止が境の前に消える経路）を捨て、止める指示の発生元を人が送った入力に限る案へ切り替えている。決定 2（loop start で消さない・コードは変えない）は実装と一致し（cmd_start の in_lap 経路は write_record のみで STOP_FILE に触れない: sprint_loop.py:138-145）、発生元を人の停止に限れば再開後に止める指示が境で効くのは意図どおりになるため、従来の指摘は解消している。前提 1 の STOP_FILE の 3 か所（cmd_stop が書く: sprint_loop.py:462 / boundary_stop が読む: sprint_loop_record.py:330 / _resume_user_stop が消す: sprint_loop.py:194）、前提 2（入力元を機械で見分けない）、前提 3/決定 3（I8 で境後の区間は経過時間から外れる）は、確定仕様とコードの読みと一致した。I1/I2 を機械で検査しない点と経緯不明の止める指示が user_stop で止まる点は『未確認のまま残ること』に明示され、隠れた欠陥ではない。設計レベルの修正提案は無い。

[takemi-ohama]

🔧 /ndf:fix サマリ | round 4 | commit 8c5982f

対応件数: critical=0 / major=1 / minor=0（合計 1 件）
決着: 1 件 / 見送り: 0 件 / 却下: 0 件
CI: SUCCESS

[takemi-ohama]

🤖 cross-review | round 5 | claude | APPROVE

このラウンドの差分（処理の流れの分岐の順序の入れ替えと説明の 1 文）に、critical / major の修正指摘はありません。セッションを終えるだけの依頼は送信元によらず F に進み、要求の E3・受け入れ条件 3 と設計の E3・F2・入出力の契約の「置かない場面」と一致しています。根拠: Value 8。

[takemi-ohama]

🤖 cross-review | round 5 | kiro | APPROVE

この版の差分はフローチャート（issues/issue-2474-design.md の『処理の流れ』）の分岐の並べ替えと確認の 1 文の追加だけで、round 4 の指摘（別のセッションからのセッション終了依頼が人への確認待ちになり、要求の E3・設計の E3/F2 の『引継ぎ文書を書いて終える』に到達しない）を直している。新しい流れは A→D（ループを止めることを求めているか）で先に分岐し、『セッションを終えるだけ』を送信元に依らず F（引継ぎ文書を書いて終える）へ送り、送信元の確認（B）はループ停止を求める文だけに掛かる。これは E3・F1・F2・F3 と整合し、全ノードが到達可能で分岐ラベルも決定と一致する。追加した 1 文も『セッションを終えるだけの依頼は送信元によらず引継ぎ文書を書いて終える（E3・F2）／送信元を確かめるのはループを止めることを求める文だけ』で図と一致する。変わった行に critical / major の修正指摘は無い。