Repository navigation
design: 設計の判断の前に外部の標準・主要な製品・既存のライブラリを調べ、自前で作る決定に比べた候補を残す(#2519) - #2523
Conversation
設計の前に外部の調査(標準・主要な製品・既存のライブラリとサービス)を通す手順の要求。 仕様の正は課題の本文で、issues/issue-2519-requirements.md はその写し。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
設計の前に外部の調査(標準・主要な製品・既存のライブラリとサービス)を通す手順を design の手順 2 に置き、 自前で作る決定に比べた候補が無い設計文書を design-survey.py の検査とレビューの観点で指摘する設計。 用語集は「作り方」「比べた候補」を足し、「自前で作る決定」「確かめられなかったこと」の意味を設計に合わせた。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
内容は足していない。平均文長 38.7→36.9 字、最長文 139→92 字。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 1 | codex | REQUEST_CHANGES
指摘 2 件(major)。
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 1 | kiro | APPROVE
設計文書のドメインモデルの節と用語集の差分を確認した。コンテキストは ndf-workflow の 1 つに収まり、集約の持ち主・不変条件 I1〜I7・ドメインイベント E1〜E8(要求の番号を引き継ぎ、受け手が各行に埋まっている)・用語の表(5 語)が用語集 docs/glossary.json・docs/glossary.md の追加と意味で一致していた。critical / major の基準に当たる食い違いは見つからなかった。
分けたファイルの設計で省いた課題が止まらないようにし、複数の課題を一度に 検査したときにほかの課題の表で番号が解決しないようにする。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔧 /ndf:fix サマリ | round 1 | commit ff13d03対応件数: critical=0 / major=2 / minor=0(合計 2 件) |
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 2 | claude | REQUEST_CHANGES
番号を 2 つ以上含む名前の設計文書(issue-7-8-design.md の形。design-match.py が既に受ける)をまとまりへ入れる規則に曖昧さがあり、決定がその課題の表で解決しない誤検出を生みうる。まとまりの作り方を 1 つに決め、テスト設計に行を足す。
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 2 | kiro | APPROVE
round 1 の I5・I6 への修正だけが差分(issues/issue-2519-design.md 1 ファイル)。省略の例外と候補番号の解決範囲を「課題ごとのまとまり」に限定する新規則を足し、外部の調査の節・省いた課題・候補の番号・no_candidates・unknown_candidate の各条件、metrics の項目(省いた課題の数)、I5/I6 のテスト設計の 2 行まで一貫して更新していた。分けた文書(-design.md と -design-decisions.md)の省略と、--issue A B での他課題の表による解決の両方が、まとまり単位で閉じる形で正しく縛られている。旧モデル(読んだ文書すべての節を合わせる/省いた文書)への取り残しは無い。critical / major に当たる食い違いは見つからなかった。
番号を 2 つ以上含む名前の設計文書を番号ごとのまとまりへ重ねて入れると、 片方の課題の表にだけある候補の番号が解決せず、正しい設計が承認ゲート 1 の 前で止まる。番号を共有する文書をつないで 1 つのまとまりにし、I5・I6 と テスト設計に複数番号の文書の例を足す。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔧 /ndf:fix サマリ | round 2 | commit f6ff69a対応件数: critical=0 / major=1 / minor=0(合計 1 件) |
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 3 | claude | REQUEST_CHANGES
課題ごとのまとまりが渡した番号で読んだ文書に依存し、1 つの番号で呼ぶ設計のプラン(--issue 8)では番号を共有する文書の決定が誤って止まる。読む文書をつながりで閉じ、単独の番号のテストを足す。
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 3 | codex | REQUEST_CHANGES
指摘 1 件(major)。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔧 /ndf:fix サマリ | commit 4158b8d対応件数: critical=0 / major=0 / minor=0(合計 0 件) |
…方を足す 設計の承認ゲート 1 での利用者の指摘(2026-11-05、直して出し直す)に合わせる。 design の手順・雛形・design-survey.py の検査は設計のまま残し、受け入れ条件 12〜17 と前提 7〜10、未決の項目 4〜6 を足した。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
設計の承認ゲート 1 での利用者の指摘(2026-11-05、直して出し直す)に合わせる。 - 観点の正本を pr-review の SKILL.md の節に置き、cross-review の review_focus.py がその節を読んで設計 PR・実装 PR の担当へ渡す(決定 10・11) - 出典の古さの基準を 90 日、担当の取得の試みの上限を 1 ラウンド 10 回、実装 PR の設計文書は担当が課題の番号から探すと決めた(決定 12〜14) - 実装を 2 つの PR(design の手順と検査 / レビューと cross-review の観点)に分ける(決定 15) - design の手順・雛形・design-survey.py の検査は設計のまま残す - 設計文書の末尾に「指摘への対応」の表を置いた 課題の本文の未決の項目 4〜6 を決まったものとして書き、受け入れ条件 17 の PR の受け持ちを決定 15 に合わせた。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
内容は足していない。章の並びは設計テンプレートの順のまま残した。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 4 | codex | REQUEST_CHANGES
指摘 1 件(major)。
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 4 | kiro | APPROVE
4 ファイル(issue-2519-design.md・issue-2519-requirements.md・docs/glossary.md・docs/glossary/glossary.json)を読んだ。要求と設計は、外部の調査の手順・雛形・機械の検査(design-survey.py)に加え、このラウンドで足した pr-review と cross-review での外部の調査の確認、実装を 2 つの PR に分ける方針まで一貫している。設計が既存コードについて断定している要点(review_focus.py の _auto_review・replace_auto_categories・_classify_changed_files・review_instructions_by_stage の model/detail、gh_sections.get_section、pr-review-steps.py の perspectives が ## 観点 を丸ごと写す、sprint_waves.py の _review_steps(n, copy) が requirements-recheck の後に単一の課題番号で回ること)を実ファイルで確認し、すべて実在・一致していた。前のラウンドで出た I5・I6 のまとまりの範囲(番号の共有を推移的にたどって閉じる・--issue N でも読む文書をつながりで閉じる)への指摘は、入出力の契約の判定の規則とテスト設計の両方に取り込まれ、単一番号で呼ぶ設計のプラン(--issue 8)でも判定が渡す番号で変わらない形になっている。critical / major に当たる食い違いは見つからなかった。修正アクションのある指摘は無い。
機械の検査が通す「省く:」の設計を、pr-review と cross-review が major として指摘しないように揃える。 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🔧 /ndf:fix サマリ | round 4 | commit e614d5f対応件数: critical=0 / major=1 / minor=0(合計 1 件) |
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 5 | claude | APPROVE
round 4 の指摘(レビュー観点の「比べた候補が無い」にまとまり単位の省略の例外が無い)への修正だけが差分。248 行の例外は I5(52 行)と入出力の契約の「課題ごとのまとまり」「省いた課題」「no_candidates」(207〜215 行)と同じ範囲で書かれ、理由の無い 省く: は同じ表の 1 行目(外部の調査の節)が別に major で拾うため、機械の検査とレビュー観点の判定は食い違わない。修正アクションのある指摘は無い。
takemi-ohama
left a comment
There was a problem hiding this comment.
🤖 cross-review | round 5 | kiro | APPROVE
このラウンドの差分は issues/issue-2519-design.md の 1 行(248 行、設計 PR のレビュー観点「自前で作る決定」)だけ。前ラウンドの指摘(248 行の観点に I5 と同じまとまり単位の省略例外を明記する)への対応で、I5(55 行)・I6(56 行)・判定の規則の 課題ごとのまとまり(209 行)/省いた課題(212 行)/no_candidates(213 行)、決定 3 の 省く: <理由> の形、テスト設計の I5「指摘しない例」と一貫していた。観点は決定 5 でレビューと手動確認が持つ側であり、テスト設計で手動確認に委ねる既存方針とも矛盾しない。critical / major に当たる食い違いは見つからなかった。修正アクションのある指摘は無い。
🔧 /ndf:fix サマリ | commit (なし)対応件数: critical=0 / major=0 / minor=0(合計 0 件) |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MVV 判定(関門 1(設計の承認))
理由
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KYHP82Dr4cwpSUc7G3LpCc
#2519 の要求と設計を文書にまとめ、用語集へ 5 語を足しました。この PR は設計の段階のもので、プラグインの実装は変えていません。
利用者向けの変化
移行の手順
変更の要点
pr-review・cross-review)で外部の調査を確認することを含む--issueで読む文書を、番号のつながりで閉じる。I5・I6 の範囲もこのまとまりに揃えるpr-reviewとcross-reviewでの外部の調査の確認と、実装の PR の分け方を書いた変更したファイルは 4 つで、追加が 755 行、削除はありません。
テスト
モード: standard / 通した工程: 要求と受け入れ条件 → 設計 → ドキュメント再構成 → ドキュメントレビュー
🤖 Generated with Claude Code
決めたこと
issues/issue-2519-design.mddesignの手順 2 に置き、以後の手順を繰り下げるexternal-survey.mdの 1 か所に置く省く: <理由>の 1 行だけを置く作り方:と比べた候補:の 2 行を置き、候補を外部の調査の表の番号で指すdesign-survey.pyにし、設計文書の探し方をdesign-match.pyとlib/design_docs.pyで共有するdesignの手順 5 から打ち、継続的統合には置かないlegacy-refactorでも外部の調査を通すため、このモードの設計文書を 4 節(現状の構造・変更後の構造・外部の調査・決定の記録)にするpr-reviewの SKILL.md の節に置き、cross-reviewはその節を読むdesignかcodeを持つ PR に載せ、プロファイルが既定の分類を外しても載せるdesignの上限(30 回)とは別の値にするdesignの手順と検査、2 つ目にレビューとcross-reviewの観点を置く