Skip to content

Release: ndf v10.27.19 を main へ - #2532

Merged
takemi-ohama merged 49 commits into
mainfrom
release/v10.27.19
Nov 5, 2026
Merged

takemi-ohama merged 49 commits into
mainfrom
release/v10.27.19

Conversation

@takemi-ohama

Copy link
Copy Markdown
Contributor

ndf v10.27.19 を main へ出す(開発版の PR #2531)。

🤖 Generated with Claude Code

takemi-ohama and others added 30 commits November 4, 2026 08:38
課題の本文の写しを issues/ に置き、要求で使う語(プランの参照・解決の記録・承認時の値)を用語集へ足した。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#2335 の柱 P5 の設計。プランは版・記録の PR・前のプランの結果・設定・予算を参照で持ち、参照の部品がステップの直前に解決して実行の記録へ残す。プランのファイルは書き換えない。解決できなければ stopped、承認時の値と食い違えば gate で返す。

- 本体 issues/issue-2344-design.md(434 行)と決定の記録 issues/issue-2344-design-decisions.md(決定 11 件)
- 要求の未決 5 件のうち 4 件を決定 1・3・4・7 で決めた。残る 1 件(柱 P3・P6・P8 の設計が変わったときの読み直し)は「未確認のまま残ること」に置いた
- 用語集に「解決の控え」「形を決めた設定」「プランのハッシュ」を足し、「版の記録」「版の差し込み」の意味を変えた

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 長い文を分け、列挙と対比を表・箇条書きへ移した
- 処理の流れ・構成要素の章を小見出しで分けた
- JSON のキーを指す「鍵」を、本文の他の箇所と同じ「キー」にそろえた

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
設計はプランを書き換えず、差し込み前のプランのコピーを作らない。決め直しは
解決の控えの版の行を上書きし、前の版と理由を履歴に残す。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
章の並びは設計文書のテンプレートの順のまま変えない。内容は足さない。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 承認時の値との食い違いと完了したプランの変更の gate を終了コード 10(EXIT_GATE)にそろえる
- 作業場所と branch の参照を作業ツリーの前に resolve_head で解決し、I3 の順序に入れる
- 版の決め直しで旧版のステップの記録を superseded へ退避し、新版の先頭から流す手順を決める
- --version の明示の版を版の参照の explicit に入れ、既出の判定と承認した版の照合を通す

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
決め直した世代は新しい耐久ワークフローとして先頭から始め、旧版の耐久ステップの記録を再利用しない。
用語集の検査に合わせ、作業ツリーを worktree と書く。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 事前判定は実行条件の評価と形を決めた設定の照合を先に行い、飛ばす・食い違うプランでは版を照会せず退避もしない
- キューの接頭辞は耐久ステップ admit_step の中で決まり再開で再生されるため、決め直したら launch_queue を fresh で開く

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
章の順は設計文書の雛形どおりで並べ替えは無い。内容は足していない。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
利用者向けの 34 の操作を、取得と削除は鍵の query の繰り返し、作成・更新・操作は本文の配列にした。
各操作に操作の扱い(x-ndf-access)・要素の鍵(x-ndf-keys)・作った識別子(x-ndf-id)を持たせ、
委任の 3 操作(delegations.yaml)を足した。契約から操作の表(src/generated/operations.ts)を生成し、
形・扱い・記録へ写す鍵を検査で確かめる。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
操作の登録の層(routes/operation.ts)が、経路の登録・要素の数と重複の検査・経路のアカウントの解決・
要素ごとの実行を、すべての利用者向けの操作に同じく掛ける。スプリントの実行・開発ループ・チームの作成に
作成の冪等の鍵を足し、鍵の行を作るものと同じトランザクションで書く。画面の API クライアントは要求を
操作の表から組み、詳細・工程の中身・バックログ・ループの詳細を要素の数によらず 1 回の要求で読む。
ソースの検査に、要求の経路を文字列で直に組む書き方を落とす規則を足した。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
委任の資格情報(ndfd_<ID>_<秘密>)を人が画面で発行し、秘密は SHA-256 だけを保存する。
要求のたびに表を強い整合で読み、期限切れと取り消し済みは 401 にする。操作の登録の層が、
扱い human の操作を範囲によらず 403 human_only、読み取りだけの範囲の書き込みを
403 scope_insufficient で断る。委任の画面(/delegations)を足し、画面の地図に行を足した。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
認証より外の中間処理が、成功・一部の失敗・400・401・403・404 のどれでも記録を 1 件追記する。
記録は許可した鍵の値と固定の列だけで組み、要求の本文を写さない。呼び出し元の種類は資格情報の種類と
MCP の内部の印だけで決める。追記に失敗したら記録の全体を構造化ログへ出し、503 audit_unavailable を返す。
保存の実装は追記の関数だけを持ち、表が無い間は構造化ログへ出す。ログの行に要求の識別子を足した。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
POST /mcp で MCP の要求を状態を持たずに受け(@modelcontextprotocol/server 2.4 の Web 標準の受け口)、
操作の表から作ったツールの呼び出しを、委任の資格情報を付けたまま同じアプリへ内部の要求として送る。
認証・範囲の照合・要素の検査・認可・記録は API と同じ処理を通り、記録の呼び出し元の種類は mcp になる。
受け口は委任の資格情報だけを受け、画面と違うオリジンは 403、GET と DELETE は 405 にする。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ndf-factory-service-boundary.md が 516 行で上限 500 行を超え、doc-line-limit-check と pytest が落ちていた。
節は factory/contracts の操作の表を正とする契約の形のため、契約の定義と型の確定仕様へ移し、参照 6 件の行き先を合わせた。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#2384 を実装する(スプリント lfactory3-4)
予定の 3 行(承認・請求と使用量・手元のマシン)の載る機能の末尾に、作る課題の番号と題を括弧で添える。冒頭の手順に、作る課題がその行を「あり」へ変えるときの扱いを足す。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
#2431 を実装する(スプリント lfactory3-4)
….ts#recordOf

委任の資格情報の頭 ndfd_ を delegations/model.ts の CREDENTIAL_PREFIX に寄せる。
auth/resolve.ts の DELEGATION_PREFIX をそこから組み、判定を isDelegationAuthorization として公開し、
認証の分岐(E2)と操作の記録の via の判定(I16)が同じ関数を使う。
delegations/service.ts の値の正規表現も CREDENTIAL_PREFIX から組む。振る舞いは変えない。

Item-Id: I-001
Impl-Runtime: claude
Impl-Model: claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…s#positiveInt

factory.ts と sprint-views.ts が実行時に互いを読む循環を外す。入力検証の positiveInt を
共通の経路層 routes/operation.ts へ移し、両方がそこから直接読む。factory.ts からの再公開は残さず、
sprint-views.ts の FactoryDeps は type import のままにする。影響範囲は routes の 3 ファイルだけで、振る舞いは変えない。

Item-Id: I-002
Impl-Runtime: claude
Impl-Model: claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…yRunsTable.createRun

createRun の拒否の判定を refuseCreate に、全条件が通った後の書き込みを commitCreate に抽出した。
拒否条件の順序と「どれかが当たれば何も書かない」境界をメソッドの切れ目で示す。振る舞いは変えていない。

Item-Id: I-003
Impl-Runtime: claude
Impl-Model: claude-opus-5-5
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
設計の承認ゲート 1 の利用者の指摘に合わせる。
- 要求: 予算と宣言の値を参照で持つ部分を外し、受け入れ条件 1 を版数と記録の PR に縮め、秘密の入力の受け入れ条件を消した(以降の番号を詰めた)
- 決定 4 を「設定の値と予算は参照にせず、組んだ時点の設定とも照らさない」にした
- 不変条件から形を決めた設定の照合(旧 I7)と秘密の設定(旧 I9)を消し、I3 と版の決め直しの事前判定から設定の照合の段を外した
- 参照の種類から setting・budget を、構成要素から設定の契約を外し、差し込みを書く 7 ファイルを検索で数え直した
- 用語集から「形を決めた設定」を消した

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 処理の流れの「流れの決まり」から、退避の手順と耐久ワークフローの世代の決まりを別の節へ分けた
  (119 行の章のうち、この部分は 26 行の 1 節だった)。節を指す参照を新しい節の名前へそろえた
- 100 字を超える文 3 つと、決定の記録の長い文を分けた。内容は足していない
- 「参照の段」を、参照の仕組みの Pull Request・参照の解決へ言い換えた

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
takemi-ohama and others added 19 commits November 5, 2026 00:58
2026-11-05 の利用者の判断(直して出し直す)に合わせ、要求の写しを作り直し、設計を置き換えた。
- 会話の記録から、lfactory2 の止める指示は conductor が別のセッションの「終了して」を読み替えて置いたものと確かめた
- conductor の手順(loop.md)で止める指示の発生元を人が送った入力に限り、終える依頼では置かない
- loop start で止める指示を消す処理と、経過時間・周回一覧・時刻の補正の変更を外し、コードは変えない

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- 「確定仕様の直し方」を「処理の流れ」の直後へ移し、何をどう書くかの章を決定の記録の前にまとめた
- 決定の根拠の Value の番号に題を添えた。「どの段にも」を「どちらの会話の記録にも」に置き換えた
- 内容は足していない(行数 216 → 216)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- キューがステージの前に worktree を作る耐久ステップは、上位の欄に参照を持つプランを作らない
- 耐久ワークフローの接頭辞の中身鍵をプランのハッシュから取る
- 本番のエントリポイントの契約に、承認した版と照らす版の参照を足す
- 決め直しの事前判定の前に流し直しの判定を置き、流さない完了したプランを外す

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- startSprintRun と startLoop の再送で、鍵が指す実行・ループが要求のアカウントに属さなければ forbidden にする
- 同じ鍵の先行の要求が途中で作り終えたときは、枠・持ち分・名前の断りより先にその結果を返す
- 要素の中の ApiError でない例外もその要素の 503 にし、ほかの要素の成功の結果を残す(#2384 の決定 3)
- 画面の作成は、結果が分からない失敗(503・通信の失敗)の後の同じ中身の送り直しで同じ冪等の鍵を使う

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
送信元の確認を、ループを止めることを求める文だけに掛ける。要求の E3・受け入れ条件 3 と設計の E3・F2 に揃える。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
結果が分からない失敗の後の再送は同じ冪等の鍵で前の発行を credential: null で返す。
画面が黙って受けると使えない有効な資格情報が残るため、取り消して発行し直すよう知らせる。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
requireEnv の写しが 5 か所・ログインの確認が 12 画面に増えたことを反映し、
ログインの確認を画面の枠の経路 1 か所へ寄せる形、createTeam の冪等の鍵の行を
保つ transact の並び、ensureUser・createTeam も含めた writeOr の形を決める。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
プランの参照: プランを作り直さずに版・記録の PR を流す直前の値で使い、承認時の値と食い違えば止まる(#2344)
内容は足さず、文の分割・表と箇条書きへの置き換え・小見出しの追加・
直訳の和語の置き換え(入口→エントリポイント、束ねる→バンドルする)だけを行った。

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
factory/: 見送ったリファクタリングの提案 20 件を片付け、同じ役割の関数を 1 か所へ寄せる(#2199)
開発ループ: 止める指示を人が送った停止だけから置く(#2474)
@takemi-ohama

Copy link
Copy Markdown
Contributor Author

振り返り(2026-11-05)

対象: issue #2384 / issue #2431 / PR #2532(正式版 ndf 10.27.19 の配布)

スプリント lfactory3-4 は、Factory の画面で行える操作を API と MCP からも同じく行えるようにした(#2384: 委任の認証・配列の入出力の契約・追記だけの操作の記録・MCP の受け口)。あわせて、画面の地図の「予定」の画面に作る課題を書いた(#2431)。実装は PR #2512(#2384)と PR #2517(#2431)、検査はスプリントの Pull Request #2518、確定仕様化は PR #2536 で行った。

リリース後テストでは受け入れ条件 32 件がすべて合格した( #2531 (comment) )。保留は 2 件で、MCP の手動確認(Factory の本番の URL が無く未実施)と、設計の決定 15 からのずれである。

何が起きたか

観点 事実
受け入れ条件 途中で変えた条件は無い。32 件をタグ ndf--v10.27.19 の中身で確かめた
手戻り #2384 の実装で全体テストが 1 回落ち、修正 1 回で通った。文書の検査も 1 回落ち、修正 1 回で通った。#2431 は手戻り 0 回
検査 構造改善は提案 39 件のうち 3 件を採用し、取り消し 0 件。残り 26 件は時間の上限(4.7 分)で見送った。レビューは 3 ラウンドで指摘 5 件、5 件とも直した
見落とし 設計は「実装は 4 本の Pull Request に分ける(決定 15)」としたが、実装は PR #2512 の 1 本(79 ファイル・追加 5,758 行・削除 1,876 行)になった。どの工程も止まらず、リリース後テストで見つかった(#2539 として起票)
承認ゲート 1 の材料 2 件とも、MVV 判定が要求の検査(requirements-check)の exit 2 を材料の欠けと読んだ。リリース後テストでタグの中身から打つと 2 件とも一致した。主ディレクトリで打つと exit 2 になることは確かめたが、当時どこで打ったかの記録は無く、それが原因かは未確認。既存の #2237 と同じ形で、由来を 1 行足した
範囲 範囲を広げた判断は無い。操作の記録の保存期間と個人データの削除の求めは #2529 へ外した
工程 飛ばした工程は無い。MCP の手動確認は配布の後へ回した

検査の記録の集計と閾値

check-trigger.py stats(10.27.16)の結果:

項目 値
トリガーの評価 0 回(立った 0 回)
検査の記録 59 回(すべて Pull Request を指す。落ちた 37 回・マージまで通った 22 回)
検査の後に逃げた不具合 0 件(結び付いた 0 件・結び付かない 0 件)
このスプリントの検査(PR #2518) マージ。構造改善の採用 3 件・取り消し 0 件、レビュー 3 ラウンド・指摘 5 件・修正 5 件

閾値は見直さない。 理由は 2 つある。

  • トリガーの評価が 0 回で、閾値(点数 15・変更量 5,000 行・逃げた不具合・24 時間)が一度も判定に使われていない。このリポジトリは pace: auto で回しており、auto はスプリントごとに必ず検査を通すため、評価(check-trigger.py eval)を呼ばない(development-workflow の references/pace.md の 163 行目)。閾値が厳しすぎるか緩すぎるかを決める材料が無い
  • 逃げた不具合が 0 件で、検査を締める根拠が無い。このスプリントのリリース後テストでも不具合は 0 件だった

残リスク: 逃げた不具合の 0 件は、記録(check-trigger.py escape)が打たれた件数である。不具合が配布の後に見つかっても記録を打つ工程を通らなければ 0 件のまま残る。打たれずに漏れた件があるかは確かめていない。落ちた 37 回は、同じ Pull Request で通るまでやり直した回で、閾値ではなく検査の安定性の数である。

context window の大きさ

conductor の 3 つのセッションを測った(supervisor と worker は claude -p で起動しており、この測定に出ない。費用はフェーズの報告にある)。

層 フェーズ モデル 件数 固定費の中央値 実作業の中央値 実作業 < 固定費 最大充填の最大 目印
conductor - claude-opus-5-5 3 45425 66105 1 136419
層 件数 固定費の合計 実作業の合計 総消費
conductor 3 161042 203649 364691
フェーズ supervisor supervisor の実作業 worker の件数 supervisor と worker の固定費の合計 目印

目印の付いた行は無い。フェーズの報告の費用は、#2384 の実装 $17.045(6,801 秒。うち実装の作業 $13.211)、#2431 の実装 $0.607、検査 $2.701、確定仕様化 $2.339、リリース後テスト $2.067 だった。#2384 の実装が全体の約 7 割を占め、1 本の Pull Request に 4 本分の実装が入ったことと一致する。

承認ゲートの差し戻し

未記録(gate-rejections.py count が終了コード 3。周回の状態ファイルの範囲に承認ゲートの答えの行が無い)。

MVV を見直すか

project-mvv.py signals(MVV 版 5):

兆候 件数 閾値
覆し 7 件(従うを退けた 0・反する疑いか判定できないを通した 7) 3
判定できない 0 件(続けて 0 回) 5(続けて 3)
流出不具合 0 件 3

覆しが閾値を超えたため、改訂の提案を人へ戻す(この振り返りは人に問えない起動で回しており、改訂するかを AI は決めない)。7 件はすべて、MVV 判定が「反する疑い」か「判定できない」を返した承認ゲートを利用者が通したものである。このスプリントの 2 件は、材料の読み違い(要求の検査の exit 2・#2237)から来ている。改訂の前に、覆しのうち材料の読み違いが原因のものと、MVV の文面が原因のものを分けて数えると、直す先(MVV か、判定の材料の集め方か)を決めやすい。

次に変えること

変えること 落とし先 状態
設計で決めた実装の分け方を実装のプランへ写す。写せないときは実装の前に止めて人へ戻す development-workflow のスプリントのプランの組み立て #2539 として起票
承認ゲート 1 の MVV 判定が、要求の検査の exit 2 を材料の欠けと読まないようにする development-workflow の MVV 判定の材料 既存の #2237 に由来を追記
検査のトリガーの閾値 .ndf/pace.json 変えない(評価 0 回・逃げた不具合 0 件で材料が無い)
MVV の改訂 プロジェクト MVV 人の判断待ち(覆し 7 件・閾値 3)

途中で起票した課題

番号 何を見つけたか 見つけた場面
#2529 操作の記録の保存期間と、個人データの削除の求めへの応じ方が決まっていない 実装中・レビュー中
#2539 設計の実装の分け方が実装のプランに写らない 振り返り(取りこぼしとして起票)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant