Freeze Opus P28-02 equivalence contract before product optimization
This commit is contained in:
Codex
+119
@@ -0,0 +1,119 @@
|
||||
# P28-02 の改善の契約：T1（snapshot の変換・コピー）だけを先に（候補 r02。DIAG の通常の final の後に、Root が照合してから登録する）
|
||||
|
||||
- 状態: 候補です。登録、worker、engine、新しい試験は、まだ行いません。根拠は DIAG の S `d6ce6dd` の bundle です（DIAG の正式な独立レビューは、そのセッションの結果だけを待ちます）。
|
||||
- 原本の条件: P28-02 の work、acceptance、横断条件6件は、`execution/p28-02/SPEC.md` §1 のとおりで、変更しません。原本は 23/88、4/30 のままです。新しい数値、原本の分母、保護、課金は変更しません。
|
||||
|
||||
## 1. T1 だけにする判断
|
||||
|
||||
- 原 work は「snapshot変換・検証・コピー・経路接続の**実測上位から**改善する」で、4つの分類の全てを変えることは求めていません。
|
||||
- T1（I11 PUBLISH_SNAPSHOT、平均 約 81 ms/tick。tick の外の Runtime の create_snapshot の独立の計測が 約 77 ms）は、分類「snapshot変換・コピー」に直接あてはまり、分類にはっきり入るものの中で、実測で最も上位です。
|
||||
- T2（I10 の中の PathService の query）は、「経路接続」に探索を含めるかどうかの解釈の差があるので、今回は選びません。その理由は、受入の記録に残します。
|
||||
- I4 は、分類の根拠が無いので、範囲の外です。
|
||||
- whole-unit の独立レビューが、この選定は不十分だと判断した場合は、changes_requested として受けます。
|
||||
|
||||
## 2. 2つの task と、source の範囲（1407 の固定への適合）
|
||||
|
||||
- **P28-02-EQ**（製品の変更なし）: allowed_paths は `docs/plans/original-completion-2026-10-02/execution/p28-02/eq/**`。同等性の harness・driver・checker・試験と、比較の collector（§4）を置きます。import の閉包は、RESTART の D1 の6ファイル、DIAG の5ファイル（読取専用）、自分のファイルだけです。
|
||||
- **P28-02-OPT**（製品の変更あり）: 変えてよいのは、次の**既存**の製品ファイルだけです。**新しいファイルを追加すること、ファイルを削除することは、source map の対象（autoload/scripts/scenes/data/tests/assets/tools と、直下の4ファイル）では禁止**です。
|
||||
- `autoload/simulation_runtime.gd`（`_publish_snapshot`、`create_snapshot`、`latest_snapshot`、`latest_digest` の周辺）
|
||||
- `scripts/core/simulation_snapshot.gd`
|
||||
- `scripts/world/world_service.gd`
|
||||
- `scripts/world/route_subslot_path_adapter.gd`
|
||||
- `scripts/world/path_service.gd`（`create_snapshot` の部分）
|
||||
- `scripts/core/command_queue.gd`（`create_snapshot` の部分）
|
||||
- OPT の試験は `docs/plans/original-completion-2026-10-02/execution/p28-02/opt/**`（source map の外）に置き、EQ の harness と一緒に実行します。
|
||||
- 理由: 既存の DIAG の driver（`diag_p28_02.py:101`）と RESTART の `restart_pair.py:189` は、source の件数を `== 1407` で固定しています。OPT が source の件数を変えなければ、両者を**変更せずに**、OPT の S でもそのまま実行できます。両者は、実際の commit と source map を全部記録するので、別の版の測定を、元の版の 1407 の測定として装うことにはなりません。全 roster の suite の数も、192 のまま変わりません。
|
||||
- EQ の比較の collector（`eq/compare_versions.py`）は、次のことを確かめます。追加、欠落、登録されていない差分が1つでもあれば、拒否します。
|
||||
- before の全 source map は、登録の base の product source map で、1407件・SHA `651f7036…`。
|
||||
- after の全 source map の差分の集合が、上の OPT の許可ファイルのうち、実際に変更したものと完全に一致すること。追加と欠落は0件。
|
||||
- after の版の EQ・DIAG・collector・RESTART のファイルの bytes が、それぞれの固定した SHA と一致すること。
|
||||
|
||||
## 3. 同等性 E1〜E5（EQ で凍結する。R と O の両方で行う）
|
||||
|
||||
- 共通: R は DIAG と同じ起動の6段階を使います。O は新規開始（Ops ON、360分）を使います。B1 の後、K=30分を手動の stepping で進めます。
|
||||
- **E1 全状態**:
|
||||
- 範囲: S 層、`latest_snapshot`、`latest_digest`、K 層、C 層。
|
||||
- 時点: B1 と、30分の各 tick の最後。
|
||||
- 比較: `var_to_bytes` の完全一致を第一とします。不一致の場合に限り、RESTART の修正8の完全な typed の正規表現で比べ、dict の列挙の順序だけの差の path を全て記録します。それ以外の差は不一致です。
|
||||
- **E2 全イベント**:
|
||||
- B1 の直後から、30分目の tick_completed の後まで、`DomainEventStream.subscribe(&"*", …)` で、全件を上限なく、全ての欄とともに順序どおりに記録します。終わったら `unsubscribe` します。
|
||||
- 開始の時点の counter と published_ids の数の一致、終了の時点の counter の一致を確かめます。
|
||||
- tick ごとの `snapshot_published` / `state_updated` の回数と順序も一致させます。
|
||||
- **E3 失敗時の拒否**:
|
||||
- 対象の API: `restore_snapshot`、`SimulationSnapshot.validate`、`load_from_path`。
|
||||
- 入力: key の欠落、型の違い、範囲外の値、重複した ID、改ざんした `world.bin`。
|
||||
- 要求: code が変更の前と同じであること。拒否の前後で、S/K/C 層と全イベントが不変であること。load の失敗が `X(B, SAVE_LOAD_FAILED)` と完全一致すること。
|
||||
- **E4 キャッシュの古さ**:
|
||||
- 場面: 状態を変えるコマンド、tick、`restore_snapshot`、`load_from_path`、状態を変えないコマンド。
|
||||
- 要求: それぞれの直後の `create_snapshot()` と `latest_snapshot` が、変更の前の版の同じ場面と E1 の方法で一致すること。
|
||||
- **E5 所有権**:
|
||||
- 対象: `create_snapshot()` の戻り値、`latest_snapshot`、`snapshot_published` / `state_updated` の引数。
|
||||
- 外から内: 入れ子の dict と配列を外から変更しても、内部の状態、次の `create_snapshot()`、`latest_digest` に影響しないこと。
|
||||
- 内から外: 内部の更新（次の tick）の後も、既に返した値が変わらないこと。
|
||||
- **現在の source の E5 の読取確認**:
|
||||
- `_publish_snapshot`（`simulation_runtime.gd:12617-12621`）は、`latest_snapshot` と**同じ dict の object** を、`snapshot_published` と `state_updated` に渡しています。
|
||||
- `latest_digest` は、遅延して `latest_snapshot` から計算されます（`:151-156`）。
|
||||
- したがって、受け手が引数の dict を変更すると、`latest_snapshot` が変わり、まだ計算していない digest もその変更を反映します。現在の受け手（`main.gd:973-976`、`world_preview.gd:2018-2039`）は引数を使っていないので、実際の誤動作は観測されていません。しかし、E5（外から内）の試験は、**現在の source で失敗すると予想します**。
|
||||
- **判定の扱い**:
|
||||
- harness の正しさは、前の版どうしを比べて差が0であること（決定性）で確かめます。これは E の合格とは別のことで、「全 E の合格」とは扱いません。
|
||||
- E3 と E5 は、版ごとの絶対の検査です。前の版で失敗したもの（上の E5 を含む）は、**既存の不具合として記録**します。その修正が OPT の許可範囲にあるもの（上の E5 は `simulation_runtime.gd` の中）は、OPT に含めます。許可範囲の外のものは、判断に戻します。
|
||||
- OPT の後の版では、全ての E の合格を要求します。
|
||||
|
||||
## 4. 比較（全て pin する。Root が実行し、版を明記する）
|
||||
|
||||
共通の引数:
|
||||
- `--readonly <collector の元の runtime の build/p28-01-readonly（元の manifest の destination root）>`
|
||||
- `--fixture artifacts/original-completion-2026-10-02/p28-current1299-runtime-scale-build-candidate-native-r01/fixture/reference.variant`（`eb4f7700…`）
|
||||
- `--engine /Applications/Godot.app/Contents/MacOS/Godot`（`c7cccbf8…`）
|
||||
|
||||
`--output` は毎回新しいものにします。各実行は、その版の凍結した checkout（HEAD の検査済み）で行います。
|
||||
|
||||
| 比較 | 前の版 | 後の版 | 実行するもの | engine の phase の数 |
|
||||
|---|---|---|---|---|
|
||||
| (a) phase の比較（headless、手動の stepping） | 既存の DIAG の native の bundle（S `d6ce6dd`、3 PID）を**再利用**します。条件: 製品の source map が `651f7036…` で、DIAG の5ファイル・engine・fixture・設定が一致すること | OPT の S で `python3 docs/plans/original-completion-2026-10-02/execution/p28-02/diag/diag_p28_02.py --run <共通> --output artifacts/original-completion-2026-10-02/p28-02-opt/phase-after-<S>-r01` を1回実行（3 PID） | DIAG の driver（変更なし） | 後の版の1回で6（import、parse 2つ、diag 3つ） |
|
||||
| (b) frame の予算の比較（windowed、`process_real_delta`） | 既存の full9（`db9d613`、製品の source map は同じ `651f7036…`）を1回分として**再利用**し、残りの2回を `collect_p28_01.py --run <共通> --output …/frame-before-r0{2,3}` で実行 | OPT の S で `collect_p28_01.py --run <共通> --output …/frame-after-<S>-r0{1,2,3}` を3回実行 | 受入済みの collector（変更なし） | 新規5回×9（import、parse 2つ、R0・P1・P2・O0・P3・P4）= 45 |
|
||||
| (c) RESTART | — | OPT の S で `python3 docs/plans/original-completion-2026-10-02/execution/p28-01/restart/probe/restart_pair.py --run <共通> --output …/restart-after-<S>-r01` | RESTART の driver（変更なし） | 7 |
|
||||
| (d) 関連回帰 | — | OPT の S で `python3 tools/run_all_tests.py --project-root <凍結した S の checkout> --godot /Applications/Godot.app/Contents/MacOS/Godot --output …/full-roster-<S>-r01` | 正式の runner（192 suite） | 約194 |
|
||||
| EQ | EQ の final の Q で、`eq/run_eq.py --run <共通> --output …/eq-before-r01` | OPT の S で、同じコマンドで `--output …/eq-after-<S>-r01` | EQ の harness（凍結） | EQ の設計による（R と O、各1 PID 以上） |
|
||||
|
||||
- (b) で全 phase が必要な理由: collector の PHASES は固定で、P1/P2 の前の R0 は、stage0 の外挿の入力です（collector の H6）。O の phase だけを外すには collector を変えるか、PHASES を差し替える必要があり、それは正式の経路ではなくなります。O の phase の値は記録しますが、T1 の判定には使いません。
|
||||
- P1/P2 を各3 PID にするには、collector を3回実行する必要があります（1回の実行で、P1 と P2 の PID はそれぞれ1つ）。前の版は、既存の full9 を1回分として数え、重複を避けます。
|
||||
- **証拠の判定**:
|
||||
- 実測の値（前後の平均・P95・最大・各 PID の値）をそのまま示します。新しい数値の目標は作りません。
|
||||
- 「改善した」と書いてよいのは、I11（と、(b) の P1/P2 の kernel の標本）で、後の版の3 PID が前の版の3 PID と重ならずに低い場合だけです。重なる場合は「差は確認できない」と書きます。この規則は管制の提案で、独立レビューの確認を受けます。
|
||||
- 予算の false 6件は、改善が無ければそのまま残します。
|
||||
- E1〜E5 が1つでも崩れた変更は、採用しません。
|
||||
|
||||
## 5. S での実行と Q での再利用（実行した版を偽らない）
|
||||
|
||||
- (a)(b)(c)(d) と EQ の後の値は、OPT の**提出された S** で実行し、「S で実行した」と記録します。Q で実行したとは呼びません。
|
||||
- integration の後の Q で再利用してよいのは、次の全てが一致する場合だけです。それ以外は、Q で必要な検証をやり直します（source が変われば、全 roster と (a)(b)(c) を Q で実行します）。
|
||||
- 製品の source map の全件（件数と、各ファイルの SHA）
|
||||
- 試験の roster（`tests/**/test*.gd` の集合と SHA）
|
||||
- marker の契約（`completion_marker_contracts.json` の SHA）
|
||||
- `project.godot` と `export_presets.cfg`
|
||||
- engine の SHA
|
||||
- 入力の fixture
|
||||
- collector・DIAG・RESTART・EQ・OPT の各ファイルの bytes
|
||||
- runner（`tools/run_all_tests.py` と `tools/regression/*`）の SHA
|
||||
- 実行に使った readonly の入力
|
||||
- integration で main 側の他の変更が source map に入った場合は、再利用しません。
|
||||
|
||||
## 6. 依存の順序
|
||||
|
||||
1. DIAG が通常の final に達する。
|
||||
2. Root が、この契約を原本の条件と照合して、main に固定する。
|
||||
3. EQ の登録 → 実装 → validation → 独立レビュー → 統合 → final。
|
||||
4. Root が、EQ の final の Q で EQ の前の値を取る（前の版の E3/E5 の失敗は、既存の不具合として記録する）。(b) の前の版の2回を実行する。
|
||||
5. OPT を登録して実装する（許可された既存の製品ファイルだけ。前の版の E の失敗のうち、範囲の中のものの修正を含む）。
|
||||
6. 提出された S で、Root が EQ の後の値、(a)、(b) の後の3回、(c)、(d) を実行する。
|
||||
7. OPT の validation（unit と、全ての bundle の verify）。
|
||||
8. 独立した新しい Opus が、原本の work と acceptance、横断条件6件、U1/U2 を whole-unit としてレビューする。
|
||||
9. 統合 → Q での再利用の資格の確認（§5）→ final。
|
||||
10. 台帳で 23→24。
|
||||
|
||||
## 7. 担当
|
||||
|
||||
- EQ と OPT: codex `gpt-6-astra`。
|
||||
- レビュー: 独立した新しい `claude-opus-5-5`（Desktop、非同期の配送）。
|
||||
- native、比較、全 roster の実行: Root。
|
||||
+39
@@ -0,0 +1,39 @@
|
||||
OPUS_D2_SCOPE_CLARIFICATION（P28-02-DIAG。base 8c06c3b44235a52f35898b1f6263e8ee064af256 の SPEC §3.1・§3.3、D2 の「live の全状態」の境界を確定する。原本の条件、SPEC、TASK_INSTRUCTIONS、baseline は変更しない。TASK_INSTRUCTIONS の全指示は従来どおり守る）
|
||||
|
||||
この確定の位置づけ
|
||||
- 「全状態」を、製品が保存する状態（S 層）と、それに関わる、名前を挙げた有限の内部状態（K 層・C 層）の和として定める。対象を独自に除外することも、無差別な走査を足すこともしない。比較は、tick の外の各計測（snapshot の変換、scratch の restore・save・load・validator）の前と後で行う。
|
||||
- 製品の値や仕様の変更の承認ではない。診断の観測の副作用が無いことを確かめるための、比較の範囲の具体化である。
|
||||
|
||||
S 層: 製品が保存する状態（必須）
|
||||
- SimulationRuntime.create_snapshot() が返す Dictionary の全体を、var_to_bytes で完全一致させる（SimulationDigest だけでは不可）。
|
||||
- 差がある場合は、RESTART の修正8で確定した typed の正規表現（文字順の key、衝突は拒否、typeof・配列の順序・値を保つ）で path を特定して報告する。dict の列挙の順序だけの差も、path つきで記録する。
|
||||
|
||||
K 層: kernel の、保存されない内部状態（名前を挙げたものだけ。get() で受動的に読む）
|
||||
- GameClock: absolute_minute、speed、paused、snapshot_version、_accumulator（f64 の hex）、_skip_next_process、_pause_request_serial、_abort_current_tick_requested、_last_tick_advanced。
|
||||
- _phase_handlers: phase ごとの handler ID の集合を、文字で並べた一覧として比べる。Callable の同一性は比べない。
|
||||
- performance_budget: _sample_counts、_totals、_samples（metric ごとの配列）。tick の外の計測でこれらが変われば、失敗にする。
|
||||
- 前後で完全一致を要求する。
|
||||
|
||||
C 層: Runtime の内部キャッシュ（create_snapshot が書き換えうるもの。autoload/simulation_runtime.gd:134-136、:11183-11200）
|
||||
- _mvp_manifest_cache_generation、_mvp_manifest_cache_catalog の同一性（get_instance_id）、_mvp_manifest_cache の var_to_bytes。
|
||||
- 規則:
|
||||
- (a) 計測の前に cache が満たされていること（generation が現在の catalog の get_manifest_generation() と一致）を記録する。満たされていなければ、計測の外で create_snapshot() を1回呼んで満たし、その事実を記録する（cache が埋まったのは、計測より前の準備としてである）。
|
||||
- (b) 計測の区間の中で cache miss（generation か catalog の変化、または cache の bytes の変化）が起きたら、その計測の標本に cache_miss_in_sample=true を付けて記録する。値は捨てず、cache の再構築を含む inclusive の値として扱う。黙って除外したり、平均に混ぜて隠したりしない。
|
||||
- (c) 計測の後の C 層が、計測の前と完全一致すること。(b) の miss があった場合は、その後の cache が、現在の catalog から作った manifest と一致することを確かめる。古い値や他の値が残っていれば失敗にする。
|
||||
- これは、P28-02-OPT の E4（キャッシュの古さ）と E5（所有権）の診断側の前提である。create_snapshot() が cache の deep copy を返すことも記録する（:11185-11199）。
|
||||
|
||||
observer の副作用の検査（有限）
|
||||
- 診断が接続する signal（tick_started、tick_phase_started、tick_completed、path_query_measured）について、接続の前と、切断した後で、各 signal の get_connections() の件数と、接続先の object と method の一覧が一致すること（診断の分は除く）。
|
||||
- 診断で DomainEventStream に subscribe した場合は、unsubscribe の後に、subscriber の一覧が元に戻っていること。
|
||||
|
||||
scratch の参照の漏れの検査
|
||||
- scratch に渡すのは、live の snapshot の deep copy だけ。scratch の操作の後で、S 層・K 層・C 層が完全一致すること。scratch の Runtime や関連の object を解放した後に、それらの instance ID が is_instance_id_valid で無効になっていること。scratch の path は private user:// の下に限る。
|
||||
|
||||
起動の構成（未指定だった点の確定）
|
||||
- 代表入力 R は、collector の SPEC §4.3 と同じ順序で既定の autoload に復元し、main を追加する（headless）。こうすることで、同期の受け手（state_updated などに接続する main 側の処理）が、実際のゲームと同じように I11 の inclusive の区間に入る。保存の policy による autosave が区間の中で起きたら、事実として記録する。
|
||||
|
||||
対象の外（理由つき）
|
||||
- Object の参照や循環の無差別な走査、engine・描画・OS の状態、node の木の全体: 製品の永続状態でも、P28-02 の計測で変わりうる内部状態でもないため対象外とする。上の K 層・C 層・observer・scratch の検査で、診断の副作用は検出できる。
|
||||
|
||||
報告
|
||||
- 各計測の前後の S/K/C 層の SHA と一致の結果、cache の状態、observer の接続の件数、scratch の解放を、report に記録する。測れない項目は、理由つきの未測定にする（0 で補わない）。上記で決めきれない不足は、具体的な箇所を示した場合に限り blocked にする。
|
||||
+50
@@ -0,0 +1,50 @@
|
||||
OPUS_STARTUP_LIFECYCLE_CLARIFICATION（P28-02-DIAG。base 8c06c3b44235a52f35898b1f6263e8ee064af256。OPUS_D2_SCOPE_CLARIFICATION の全文（S/K/C 層、observer、scratch、main の追加）はそのまま有効で、その上に起動から終了までの境界を確定する。原本の条件、SPEC、TASK_INSTRUCTIONS、baseline、製品の値は変更しない）
|
||||
|
||||
原則
|
||||
- SPEC §3.1 の「live を変えてよいのは fixture の導入と advance_minutes(1) だけ」は、測定の区間（段階③〜⑤）の禁止として扱う。測定の前の準備（段階①②）では、下に列挙した公開の呼出しだけを行ってよい。準備による状態の変化は、その全てを raw に記録する。準備の変化を、測定の副作用や測定時間として扱わない。
|
||||
- 列挙した呼出し以外に、製品の状態を変える呼出し、製品の値の変更、関数や hook の差し替えは行わない。
|
||||
|
||||
段階① autoload と fixture の準備（collector の measure_p28_01.gd:283-334 と同じ順序。同じ guard と private profile の bootstrap を使う）
|
||||
- 許可する呼出し:
|
||||
- GameClock.set_paused(true)
|
||||
- FileAccess で代表入力 R を開き get_var(false)（SHA eb4f7700… を照合）
|
||||
- SimulationRuntime.restore_snapshot(<R>)
|
||||
- 復元の後の GameClock.set_paused(true)
|
||||
- set_paused(true) は、実時間の _process による tick を止め、時間を手動の stepping だけで進めるための準備である（simulation_kernel.gd:104-121 で、止まった状態の advance_minutes は正当な手動の stepping として進む）。set_paused(true) は paused と _pause_request_serial を変えるので、その前後の K 層の値を記録する。
|
||||
- 記録: restore の戻り値、復元後の S 層の SHA、K 層、C 層。
|
||||
|
||||
段階② main の追加（headless）と、手動 stepping の制御
|
||||
- 許可する呼出し: main.tscn を instantiate して root に add_child する。その後 process_frame を2回 await する（focus の deferred 処理のため）。
|
||||
- main の _ready の副作用（save policy の設定、Ops の開始の試行。R では INVALID_START_TIME になる）は、そのまま記録する。
|
||||
- process_frame の間に kernel の _process が _skip_next_process を消費することがある（process_real_delta は skip を paused より先に確かめる）。これも準備の変化として記録する。
|
||||
- 禁止: _set_speed、_toggle_pause、set_paused(false)。clock は段階②から段階⑥まで、ずっと paused=true のままにする。
|
||||
- この段階の終わりに、baseline B0（S/K/C 層の SHA）を固定する。observer の接続はここで行い、接続の前後の get_connections() を記録する。
|
||||
|
||||
段階③ warm（30分）
|
||||
- GameClock.advance_minutes(1) を30回呼ぶ。1回ごとに process_frame を1回 await する（main の deferred 処理を、tick の区間の外に出すため）。
|
||||
- 各呼出しの前後で absolute_minute を照合し、進まなければ失敗にする。
|
||||
- observer の記録は warm の区間として取り、統計には入れない。
|
||||
- 終わりに baseline B1（S/K/C 層の SHA、absolute_minute=632、C 層の cache の状態）を固定する。C 層の規則 (a) は、ここで確かめる。
|
||||
|
||||
段階④ 測定（30分）
|
||||
- 段階③と同じ方法で30分を進める。I0〜I11 の inclusive の区間、observer の自分の費用、path_query_measured を記録する。
|
||||
- tick と tick の間の frame の wall（tick_completed から次の tick_started まで）は、別の欄に記録し、どの phase にも帰属させない。
|
||||
- この段階の中の、状態を変える呼出しは advance_minutes(1) だけ。
|
||||
|
||||
段階⑤ tick の外の S/K/C 検査と内訳の測定（clock は paused のまま）
|
||||
- 測定の前の S/K/C を記録する。そのあと、SPEC §3.3 の N=5 の計測と、使い捨ての scratch の操作を行う。測定の後の S/K/C が、測定の前と完全一致すること（C 層は D2 の規則 (b)(c)）。
|
||||
- この段階では、時間を進めない。
|
||||
|
||||
段階⑥ 切断、解放、終了
|
||||
- observer を切断し、各 signal の接続が段階②の接続の前に戻ったことを確かめる。scratch の object を解放し、instance ID が無効になったことを確かめる。
|
||||
- 終了は collector の K1 と同じく get_root().close_requested.emit() で行い、audio の drain の結果を記録する。owned の cleanup は collector の run_private_engine と同じ。
|
||||
|
||||
3 PID の条件の一致
|
||||
- 3つの PID の間で、次のものが一致することを要求する: 入力の SHA、段階①の復元後の S 層の SHA、B0 と B1 の S 層の SHA、K 層（absolute_minute、paused、_pause_request_serial、_skip_next_process、snapshot_version、handler の集合）、C 層の状態、main の _ready の Ops の結果。
|
||||
- 一致しない項目があれば、その事実と値を記録して判断に戻す（3回の比較は成立しないものとして扱う）。時間の値（区間の wall）は、一致を要求せずに比べる。
|
||||
|
||||
worker の裁量（微小な確認ごとに止めないための指示）
|
||||
- 承認された範囲の中の通常の実装上の選択は、worker が判断して、その理由を BLOCKED.md ではなく実装の記録に残して進める。例: 関数の分け方、名前、report の構造、試験の合成データ、await の配置、記録の書式、上に列挙した許可済みの呼出しの使い方。
|
||||
- blocked にしてよいのは、原本の製品の仕様・数値・権限・課金・原本の受入に影響する未確定事項がある場合だけ。その場合は、具体的な箇所と、選択肢を示す。
|
||||
|
||||
その他（SPEC、TASK_INSTRUCTIONS、C1、両 validation、engine・製品変更・全回帰・commit の禁止、測れない項目を理由つきの未測定にすること）は、すべて従来どおり。
|
||||
Reference in New Issue
Block a user