Skip to content

design: 設計の判断の前に外部の標準・主要な製品・既存のライブラリを調べ、自前で作る決定に比べた候補を残す(#2519) - #2523

Merged
takemi-ohama merged 12 commits into
developfrom
design/issue-2519
Nov 5, 2026
Merged

takemi-ohama merged 12 commits into
developfrom
design/issue-2519

Conversation

@takemi-ohama

@takemi-ohama takemi-ohama commented Nov 5, 2026 •

Copy link
Copy Markdown
Contributor

#2519 の要求と設計を文書にまとめ、用語集へ 5 語を足しました。この PR は設計の段階のもので、プラグインの実装は変えていません。

利用者向けの変化

  • 無し

移行の手順

  • 無し

変更の要点

  • 要求と受け入れ条件を issues/issue-2519-requirements.md に書いた(231 行)
    • レビューの工程(pr-review・cross-review)で外部の調査を確認することを含む
    • 実装の PR の分け方を含む
  • 設計を issues/issue-2519-design.md に書いた(489 行)
    • 検査では、省略の例外と候補の番号の解決を、Issue ごとのまとまりの中で扱う
    • 番号を共有する設計文書を、1 つのまとまりに合わせる
    • --issue で読む文書を、番号のつながりで閉じる。I5・I6 の範囲もこのまとまりに揃える
    • pr-review と cross-review での外部の調査の確認と、実装の PR の分け方を書いた
  • 設計文書の構成を整えた
    • 長い文を分けた
    • 構成要素の章を 2 つの小見出しに分けた
    • 処理の流れを 3 つの小見出しに分けた
  • 用語集(docs/glossary.md と docs/glossary/glossary.json )へ 5 語を足した
    • 要求の側で使う語が 3 語
    • 設計の側で使う語が 2 語

変更したファイルは 4 つで、追加が 755 行、削除はありません。

テスト

  • 実行したテストのステップは無し(文書だけの変更)

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

🤖 Generated with Claude Code

決めたこと

issues/issue-2519-design.md

  • 決定 1: 調べた結果を設計の判断より先に持つため、外部の調査を design の手順 2 に置き、以後の手順を繰り下げる
  • 決定 2: 調査が設計の所要を際限なく延ばさないよう、上限を種類ごとの候補 6 件と取得の試み 30 回にし、external-survey.md の 1 か所に置く
  • 決定 3: 通したか省いたかを 1 か所で読めるよう、外部の調査の節は通しても省いても必ず作り、省くときは 省く: <理由> の 1 行だけを置く
  • 決定 4: 自前で作る決定を機械が見分けられるよう、決定の中に 作り方: と 比べた候補: の 2 行を置き、候補を外部の調査の表の番号で指す
  • 決定 5: 受け入れ条件 8 の指摘は、機械の検査と設計 PR のレビューの観点の両方で行う
  • 決定 6: 検査は新しいエントリポイント design-survey.py にし、設計文書の探し方を design-match.py と lib/design_docs.py で共有する
  • 決定 7: 検査はスプリントの設計のプランと design の手順 5 から打ち、継続的統合には置かない
  • 決定 8: 調査の結果の形は、棚卸しのシーズの調査と出典の項目だけ揃え、記録の置き場と形式は揃えない
  • 決定 9: legacy-refactor でも外部の調査を通すため、このモードの設計文書を 4 節(現状の構造・変更後の構造・外部の調査・決定の記録)にする
  • 決定 10: 2 つのレビューの担当が同じ観点を受け取るよう、観点の正本を pr-review の SKILL.md の節に置き、cross-review はその節を読む
  • 決定 11: 観点は分類 design か code を持つ PR に載せ、プロファイルが既定の分類を外しても載せる
  • 決定 12: 出典を古いと見る基準は、取得日が設計 PR を出した日より 90 日以上前、または取得日の後に新しい版か終了のアナウンスが出ていること、にする
  • 決定 13: レビューの担当の取得の試みは 1 ラウンドに 10 回までにし、design の上限(30 回)とは別の値にする
  • 決定 14: 実装 PR の担当は、設計文書のパスを渡されず、PR の題と本文とブランチ名の課題の番号から worktree の設計文書を探す
  • 決定 15: 実装を 2 つの PR に分け、1 つ目に design の手順と検査、2 つ目にレビューと cross-review の観点を置く

takemi-ohama and others added 3 commits November 5, 2026 01:02
設計の前に外部の調査(標準・主要な製品・既存のライブラリとサービス)を通す手順の要求。
仕様の正は課題の本文で、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 takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 cross-review | round 1 | codex | REQUEST_CHANGES

指摘 2 件(major)。

Comment thread issues/issue-2519-design.md Resolved
Comment thread issues/issue-2519-design.md Resolved

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 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>
@takemi-ohama

Copy link
Copy Markdown
Contributor Author

🔧 /ndf:fix サマリ | round 1 | commit ff13d03

対応件数: critical=0 / major=2 / minor=0(合計 2 件)
決着: 2 件 / 見送り: 0 件 / 却下: 0 件
CI: PENDING

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 cross-review | round 2 | claude | REQUEST_CHANGES

番号を 2 つ以上含む名前の設計文書(issue-7-8-design.md の形。design-match.py が既に受ける)をまとまりへ入れる規則に曖昧さがあり、決定がその課題の表で解決しない誤検出を生みうる。まとまりの作り方を 1 つに決め、テスト設計に行を足す。

Comment thread issues/issue-2519-design.md Resolved

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 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>
@takemi-ohama

Copy link
Copy Markdown
Contributor Author

🔧 /ndf:fix サマリ | round 2 | commit f6ff69a

対応件数: critical=0 / major=1 / minor=0(合計 1 件)
決着: 1 件 / 見送り: 0 件 / 却下: 0 件
CI: PENDING

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 cross-review | round 3 | claude | REQUEST_CHANGES

課題ごとのまとまりが渡した番号で読んだ文書に依存し、1 つの番号で呼ぶ設計のプラン(--issue 8)では番号を共有する文書の決定が誤って止まる。読む文書をつながりで閉じ、単独の番号のテストを足す。

Comment thread issues/issue-2519-design.md Resolved

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 cross-review | round 3 | codex | REQUEST_CHANGES

指摘 1 件(major)。

Comment thread issues/issue-2519-design.md Resolved
@takemi-ohama

Copy link
Copy Markdown
Contributor Author

🔧 /ndf:fix サマリ | commit 4158b8d

対応件数: critical=0 / major=0 / minor=0(合計 0 件)
決着: 2 件 / 見送り: 0 件 / 却下: 0 件
CI: NONE

takemi-ohama and others added 3 commits November 5, 2026 04:18
…方を足す

設計の承認ゲート 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 takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 cross-review | round 4 | codex | REQUEST_CHANGES

指摘 1 件(major)。

Comment thread issues/issue-2519-design.md Resolved

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 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>
@takemi-ohama

Copy link
Copy Markdown
Contributor Author

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

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

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 cross-review | round 5 | claude | APPROVE

round 4 の指摘(レビュー観点の「比べた候補が無い」にまとまり単位の省略の例外が無い)への修正だけが差分。248 行の例外は I5(52 行)と入出力の契約の「課題ごとのまとまり」「省いた課題」「no_candidates」(207〜215 行)と同じ範囲で書かれ、理由の無い 省く: は同じ表の 1 行目(外部の調査の節)が別に major で拾うため、機械の検査とレビュー観点の判定は食い違わない。修正アクションのある指摘は無い。

@takemi-ohama takemi-ohama left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤖 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 に当たる食い違いは見つからなかった。修正アクションのある指摘は無い。

@takemi-ohama

Copy link
Copy Markdown
Contributor Author

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

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

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@takemi-ohama takemi-ohama added the design-approved 設計 Pull Request の承認の印 label Nov 5, 2026
@takemi-ohama

Copy link
Copy Markdown
Contributor Author

MVV 判定(関門 1(設計の承認))

  • 判定: follow(関門を省いた。利用者が承認した MVV を事前の許可として扱う)
  • 根拠: Mission / Vision / Value 1 / Value 2 / Value 3 / Value 4 / Value 5 / Value 6 / Value 7 / Value 8 / C5 / C7 / P1(プロジェクト MVV: approved・版 5)
  • 時刻: 2026-11-05T04:36:45+00:00
  • ログ: /home/ubuntu/.local/state/ndf/mvv-gate.jsonl の 2026-11-05T04:36:45+00:00 の行

理由

  • Mission と Vision、Value 4 に照らして follow とした。NDF の外のプロジェクト carul(feat: 全 Skill の description を新書式へ圧縮する(平均 237 → 150 文字) #102・Add: cross-refactoring — 多ランタイム・リファクタリング収束ループ (#113) #117)で、比べないまま自前で作ると決めた設計をやり直した実例がある。この変更はそれを起点に、設計の承認の前に比べた候補を機械の検査とレビューで確かめる。どのリポジトリでも、設計の工程の中で同じに働く。
  • Value 2 と Value 3 に照らして follow とした。利用者の指摘どおり、実装を『design の手順と検査』と『レビューと cross-review の観点』の 2 つの PR に分けている。調査には上限(候補 6 件・取得の試み 30 回、レビューの担当は 1 ラウンド 10 回)を置き、当たったら止める。直しは 1 回だけ試み(fix-survey)、残れば止めて人へ戻す。同じ指摘のラウンドを重ねない。
  • Value 5、Value 6、Value 7 に照らして follow とした。判定の要らない検査はスクリプト(design-survey.py)に任せ、文の意味を読む確認はレビューに任せる。設計文書の探し方は lib/design_docs.py に寄せて共有し、Markdown の読み方は既存の markdown-it-py(lib/md.py)を使う。継続的統合でなく設計のプランと Skill の手順から検査を打つので、ほかのリポジトリでも働く。観点の正本は pr-review の SKILL.md の 1 か所に置き、cross-review はそれを読む。
  • Value 8 と Value 1 に照らして follow とした。決定 15 件のそれぞれに、理由と採らなかった形を残している。確かめられなかったこと(既存の検査の Tool を探していないこと、Codex で外部を取得できる範囲など)と、リリース後の測定へ回す項目を明記している。上限の値の妥当性など配布の後でしか測れない効果は、判定の対象にしない。
  • 共通原則 C1〜C8 と P1 に照らして、承認が要る操作は無いと判断した。この PR が変えるのは issues/ の要求と設計の文書、docs/ の用語集だけである。.ndf/ の設定、AGENTS.md / CLAUDE.md の運用の節、秘密、認証、利用者のデータ、配布の取得元と版の規則には触れない。後の実装の範囲(design の Skill・検査のスクリプト・sprint_waves.py・pr-review・cross-review)にも当たる操作は無く、codex の起動の引数など取得の権限も変えないと明記している。

@takemi-ohama
takemi-ohama merged commit 214ca25 into develop Nov 5, 2026
24 checks passed
@takemi-ohama
takemi-ohama deleted the design/issue-2519 branch November 5, 2026 07:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

design-approved 設計 Pull Request の承認の印

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant