指示書BJ — 制御盤のログ（指示書AY）の点検で出た指摘を直す（2026-11-05）

担当: Cursor。監督（Claude Code）がレビューする。 前提: develop の ae30f4a 以降（指示書AY の実装 3c7bcc8〜ae30f4a が入った版）。 着手時の先端: git log --oneline -1 の ID を書く: ae30f4a。ae30f4a と違っても、その間のコミットが資料（docs/・.claude/）だけなら、本書の行番号はそのまま使える。 確かめ方: git diff --stat ae30f4a..HEAD -- . ':!docs' ':!.claude' が★何も出さない★こと。何か出たら、そのファイルの行番号を開いて確かめ直す。 ★行番号はすべて ae30f4a 時点の実物で監督が確かめた値★。作業中にずれたら、書いてある文言で探す。 ★作業の前に必ず読むこと★:

• docs/handoff/指示書AY_制御盤のログをD-Secログ画面から取り出す_20261019.md の §3 表5（R43・R44）・段階7-2・段階9-2・§4 の 4-23
• components/features/ds-logs/DeviceLogsModal.tsx の apiErrorMessage()（:81-115）・一覧の取得（:260-319）・startExport()（:385-421）
• lib/ds-agent/relay.ts の submitListResult()（:457-465）・pushChunk()（:512-563）・touch()（:424-426）・markSeen()（:307-315）

0. ユーザーの指示（原文）と回答

• 「完了しました、確認してください」（指示書AY の実装の確認）。監督の点検（査読2観点・fixtures の画面・ローカルDB での偽制御盤・本物の agent.py）で、下の指摘が出た
• 指摘のうち「制御盤から形の崩れた一覧が来たとき、画面はどうするか」を問うた。選択肢は2つ:
  • A: すぐ 502 にして「制御盤の結果の形が不正です」と出す
  • B: 今のまま、15秒待ってから「応答がありません」と出す
  • ユーザーの回答: ★「Aで、指示書を書いてください」★（2026-11-05）

1. 何を直すか（全体像）

J4 の実測（監督。fixtures・1440×900・DS-002 のモーダル。JP の位置 − EN の位置）

2. API（★先に d-watch-api.yaml を直す。CLAUDE.md §6-1★）

2-1. POST /ds-agent/commands/{command_id}/result（J2）

• 本体の形が誤っていたら（parseAgentListResult() が ok: false になるもの全部。W2〜W8・W9 の error の形の誤り・W10・R44）:
  1. ★relay の新しいメソッド rejectListResult(serial, commandId)★ を呼ぶ。中身は failCommand() の list の分岐（relay.ts:500-505）と同じで、コードは "result_invalid"。★対象は kind が list の指示だけ★（export の指示や見つからないときは何もせず "not_found"）。期限切れは "gone"
  2. ★戻り値によらず★、制御盤への応答は今までどおり 400 result_invalid（parsed.error）
• ブラウザの GET /ds-devices/{serial_number}/logs は ★502 agent_error（details.agent_code = ["result_invalid"]）★ で終わる（今の agent_error の経路そのまま。ルートは変えない）
• ★その後に正しい結果を送っても受け取らない★: 指示は消えているので 404 not_found（commandNotFound()。lib/ds-agent/agent-request.ts:47-49。★新しいコードを作らない★）
• ★prepared・complete・fail の本体の形の誤りは今のまま★（400・状態は変えない。表5 R43）。今回ユーザーに問うたのは一覧だけ。準備中に形の崩れた prepared が来たときの動き（50秒で 504）は変えない

2-2. 検証の強化（J5・J6・J7）

• 一覧の types[].key: ★1文字以上・, を含まない・前後に空白が無い（key.trim() === key）文字列★。label は今のまま（文字列）。空白だけの key（" "）は、画面が types= を送ってサーバーの trim で「省略＝全種類」になり、絞り込めなくなるため
• 一覧の items[].file_id: ★1〜1024文字★（FILE_ID_MAX_LENGTH を共有する。数字を直書きしない）
• prepared の total_bytes: ★1以上の整数★（今は0以上）

2-3. d-watch-api.yaml で直す箇所（G1: ★grep で関係する語を全部探す★）

• POST /ds-agent/commands/{command_id}/result（:2046 付近の説明）: 「1件でも形が違えば結果全体を不正とする(400)」の後に「★ブラウザの一覧は 502 agent_error（agent_code は result_invalid）で終わり、その指示は消える（その後の結果は 404）★」を足す
• DsResultInvalid（:2701）: 「状態は変えない(D25 ④)」を「★形の誤りは、/result ではブラウザの一覧を 502 で終わらせ（指示書BJ）、prepared・complete・fail では状態を変えない(D25 ④)。complete の値の不一致（合計・SHA-256）はエクスポートを失敗にする★」に直す（★今の文も complete の値の不一致について誤っている★ — completeExport() は endExport() でエクスポートを失敗にする）
• GET /ds-devices/{serial_number}/logs の 502: DsAgentError（:2691）に「形の不正は result_invalid」が既にあるので★足さない★
• 一覧のスキーマ DsLogType / DsLogFile（:3641・:3649 付近）: key に minLength: 1 と pattern: "^[^,\s](?:[^,]*[^,\s])?$"（1文字以上・, を含まない・前後に空白が無い。J5）、file_id に maxLength: 1024。★この2つのスキーマはブラウザ向けの DsLogListResponse と共有している★ — 矛盾はしない（制御盤から来た値をそのまま返すので）。その旨を description に1文足す
• prepared のスキーマ DsAgentPrepared（:3769 付近）の total_bytes: minimum: 1。★ブラウザ向けの DsLogExportResponse.total_bytes（:3704 付近）も minimum: 1★（prepared の値をそのまま返す）。DsAgentComplete.total_bytes（:3777 付近）も minimum: 1 にそろえる（prepared と一致しないと失敗するので、0 は来ても必ず失敗する）
• チャンクの 409 の説明（:2112 付近「seq が連番でない・send の前」）に「★前のチャンクの 204 を待たずに次を送った（J8）。このとき保留中だった前のチャンクの POST は 410 export_cancelled で返る★」を足す
• X-Agent-Version: 今は GET /ds-agent/commands にしか定義が無い。J9 で認証の通る6本すべてが読むので、★残りの5本（result・prepared・chunks・complete・fail）にも同じパラメータを足す★（$ref で共有してよい）。説明は「接続の記録に使う。形の合わない値は無視する（拒否しない）」
• 確かめ方: grep -n "result_invalid\|total_bytes\|file_id\|key:" d-watch-api.yaml の該当行を報告に貼る

3. 画面と中継の直し方

3-1. エラーの文言（J1・J2・J12）— ★純粋関数に移して表Eでテストする★

• DeviceLogsModal.tsx の apiErrorMessage()・detailStrings()・formatFileSize()・formatDateTime()（:60-115）を ★新しいファイル lib/ds-logs/modal-text.ts に移す★（中身は下の変更以外そのまま）。モーダルはそこから import する
• apiErrorMessage() の status 0 の扱い:
  • ★e.cause が name === "AbortError" のもの（DOMException か Error）なら null★（モーダルを閉じて準備の POST を取り消したとき。指示書AY 4-23・M5）
  • それ以外の status 0 は ★t("通信に失敗しました。時間をおいて再度お試しください")★（lib/i18n.ts:551 に EN もある既存の文言。新しく作らない）
• agent_error の分岐に ★code === "result_invalid" → t("制御盤の結果の形が不正です")★ を足す（too_large と同じ形）。lib/i18n.ts に EN "The controller returned a malformed result" を足す
• J12: 一覧の取得の effect の日付の分岐（:262-274）で、queryString === null かつ日付が理由のとき、★開始日と終了日の両方が読めて開始 ＞ 終了なら「開始日は終了日以前にしてください」★、それ以外は今の「日付の範囲が不正です」。i18n に EN "The start date must be on or before the end date" を足す。判定は parseDate()（定義は lib/clean-logs/query.ts:63。presets.ts:7 が import 済み）を使い、モーダルに日付の比較を直書きしない（関数 dateRangeError(start, end): "reversed" | "invalid" | null を lib/ds-logs/presets.ts に足し、表Dで固定する）。★モーダルでは dateRangeError() の結果を useMemo で作り、一覧の effect の依存に入れる★（effect の中で period を直接読むと react-hooks/exhaustive-deps に当たる）
• ★一覧の失敗で文言が出るときは、今のコード（:302-305）のとおり一覧を空にする★（J1 で通信の失敗もここに入る）
• ★agent_error（J2 の result_invalid を含む）のときは見出しを「接続中」にする★（setConnected(true)。制御盤は結果を返しているので接続している）。今は agent_offline のときしか見出しを直さない（:306-310）ため、開いて最初の一覧が 502 だと、見出しは初期値の「未接続／最終接続 -」のまま本文だけ「制御盤の結果の形が不正です」になる。last_seen_at は分からないので今の値のまま。通信の失敗（J1）・agent_timeout では見出しを変えない（直前の値のまま）
• ★4MB を超える一覧（W8）も「制御盤の結果の形が不正です」になる★（原因は大きさだが、制御盤側の不具合であることは同じなので許容。文言を分けない）

3-2. 開いたときの問い合わせを1回にする（J10）

• queryString（:181-192）で、★selectedTypes が types の全部と一致するとき（件数が同じで、全部含む）は types を付けない★。selectedTypes === null（まだ種類を知らない）も付けない（今のまま）。★useMemo の依存に types を足す★
• ★判定は純粋関数にして表Q で固定する（必須）★: lib/ds-logs/query.ts（既存。サーバー側の queryDeviceLogs() と同じファイル）に deviceLogTypesParam(knownTypeKeys: readonly string[], selected: ReadonlySet<string> | null): string | null（null ＝ types を付けない）を足し、queryString から使う
• ★制御盤に種類が1つも無いとき（types が空配列）は「種類を1つ以上選んでください」を出さない★: noTypeSelected を selectedTypes !== null && selectedTypes.size === 0 && types.length > 0 にする（今は種類が無いだけで「選んでください」が出る）。種類が無いときは types を付けずに取り、0件の表示になる
• 帰結: 開く → 1回目（types なし）→ 全種類で埋める → queryString は変わらない → 取り直さない
• ★種類を1つ外して戻したとき（全種類に戻る）も types なしになる★。API の応答は同じ（省略＝全種類）

3-3. ボタンの幅を固定する（J4）

• ★components/ui/FilterButton.tsx は触らない★（他の6画面と共有。§8）
• モーダルの期間・並べ替えの FilterButton を、モーダルの CSS（DeviceLogsModal.module.css）の入れ物（例 <span className={styles.fixedSlot}>）で包み、.fixedSlot > button { min-width: …; } で幅を固定する。トークンのボタンは既存の .tokenButton（:317-330。今は min-width: 120px）を直す。★.tokenButton は「コピー」（DeviceLogsModal.tsx:801-807）にも付いている★ので、コピーも同じ幅に広がる。それでよいが、トークンの表示欄（.tokenReveal）の中で折り返さないことを §6 で見る
• 幅は ★JP と EN の長いほう＋余白★ にする。§1 の実測から、★期間4つ 112px・並べ替え2つ 100px・トークン（コピーを含む3つ）140px★（実測 Last 24 hours 101px・Type + date 89px・Issue (regenerate) 129px に、拡大率やフォントの差で動かないよう約10px の余裕）。★4つの期間ボタンを同じ幅にそろえてよい★（そのほうが位置が動かない）
• 確かめ方は §6 の J4（JS で測ってずれ0）

3-4. 中継（J2・J8・J9）

• J2: lib/ds-agent/relay.ts に rejectListResult(serial: string, commandId: string): SubmitResult を足す（Relay の型と relay.ts:423 の実装。lib/ds-agent/__tests__/fake-relay.ts は本物を偽の時計で包むだけなので直す箇所は無い）。submitListResult() の隣に置き、★list の指示だけ★を { kind: "agent_error", code: "result_invalid" } で解決して commands から消す。ds_logs.list のイベントは今の agent_error の経路で agent_code: "result_invalid" が出る（★新しいイベントを作らない★）
• J8: pushChunk() の seq の照合（:520）の★前★に、rec.pendingPush !== null なら endExport(rec, "failed", "chunk_out_of_order", { agentCode: "chunk_out_of_order" }) して "out_of_order" を返す。endExport() が先の POST を "cancelled" で返し、flowTimer も消す（:370-371・:388-389。今のまま）
• J9:
  • app/api/ds-agent/commands/route.ts:16・:27-28 の版の読み取り（正規表現 /^[0-9A-Za-z.+-]{1,32}$/）を ★lib/ds-agent/require-agent.ts の関数 agentVersionOf(request): string | null★ に移し、commands ルートもそこから import する。★agent-request.ts には置かない★（agent-request.ts:8 が既に require-agent.ts を import しているので、置くと import が循環する）
  • requireAgent()（lib/ds-agent/require-agent.ts:21）は getRelay().touch(serial, agentVersionOf(request)) を呼ぶ。touch() の型を touch(serial: string, agentVersion: string | null): void にし、中で markSeen(device(serial), agentVersion)
  • ★形の合わない版は今までどおり無視する（null。拒否しない）★
  • ★touch() の agentVersion は省略可（?）にしない★ — 省略すると undefined が markSeen() の !== null を通って版に入る。必須にして、呼んでいる箇所を全部直す（罠7）

4. 期待値表（★監督が確定。テストはこれをそのまま使う★）

表E — lib/ds-logs/modal-text.ts（新規テスト lib/ds-logs/__tests__/modal-text.test.ts。t は渡した文字列をそのまま返す関数）

ApiFetchError の作り方は lib/api/client.ts:47-60 のコンストラクタ（{ status, code, serverMessage, details?, cause? }）。

表D — dateRangeError(start, end)（lib/ds-logs/presets.ts。lib/ds-logs/__tests__/presets.test.ts に足す）

★periodFromDates() の T5〜T9 は変えない★（T9 は今までどおり null）。

表R — 中継とルート（lib/ds-agent/__tests__/relay.test.ts・app/api/ds-agent/__tests__/routes.test.ts）

表T — テストの補強（J3・J11）

表Q — deviceLogTypesParam(knownTypeKeys, selected)（lib/ds-logs/query.ts。lib/ds-logs/__tests__/query.test.ts に足す）

★G3: 足したテストは、一度わざと壊して赤になるのを確かめてから戻す★（例: J8 の判定を消す → R49 が赤、rejectListResult() を呼ばない → R43′ が赤、T-b は relay.ts の pushChunk() に一時的に (await import("node:fs")).writeFileSync("sabotage.tmp", "") を足す → ★T-b のテスト名で赤★になること（ソースの静的検査のテストも赤になるのは想定内）。★T-b のスパイは mockImplementation(() => undefined) にして本物を呼ばない★（vi.spyOn だけだと本物が呼ばれてファイルが書かれる）。壊した変更はコミットしない。

5. 段階（この順で。段階ごとにコミット）

1. 着手前: 冒頭の「着手時の先端」を書く。git status --short で ★他のセッションの未コミットの変更★（今は components/features/errors/ErrorContentPicker.tsx・lib/errors/error-content-label.ts とそのテスト）を確かめ、★触らない・コミットに含めない★。npx vitest run の件数（前）を控える（ae30f4a で 169ファイル・4,260件）
2. テストの土台: T-a（J3）。★全件を3回走らせて3回とも全件通過★を確かめてからコミット
3. d-watch-api.yaml（§2-3）
4. 検証と中継: J5・J6・J7（validate.ts）、J2（relay.ts・/result ルート）、J8、J9（agent-request.ts・require-agent.ts・commands ルート・relay.ts）＋表R
5. 画面: lib/ds-logs/modal-text.ts（新規）＋表E、dateRangeError()＋表D、deviceLogTypesParam()＋表Q、DeviceLogsModal.tsx（J1・J2 の文言と見出し・J10・J12）、DeviceLogsModal.module.css（J4）、lib/i18n.ts（EN 2つ）
6. テストの補強: T-b・T-c・T-d（T-e＝表Q は段階4 で）
7. 資料: docs/logging-design.md（ds_agent.connected の agent_version が認証の時点で入ること。ds_logs.list の agent_code に result_invalid が出ること）、docs/decisions.md の D-179 の末尾（指示書AY の「実装の記録」の後ろ・D-180 の見出しの前。★D-179 の本文と AY の記録は書き換えない★）に §9 を足す
8. tsc・lint・npm run build・vitest 全件（★3回★）の件数と、段階ごとのコミットを報告（★報告は日本語★）

6. 画面で確かめること（fixtures）

手順は指示書AY 段階11-2 と同じ（USE_FIXTURES=true npm run build → USE_FIXTURES=true と試験用の AUTH_TOKEN を環境変数で渡して npx next start -p 3100。★:3000 は触らない★。終わったら :3100 を止める。★止める前に、Get-NetTCPConnection -LocalPort 3100 -State Listen の OwningProcess のコマンド行が自分の next start -p 3100 であることを確かめる★ — 2026-11-05、親を止めても子の node が :3100 に残った。コマンド行は next\dist\bin\next" start -p 3100 のように next の後に引用符が入るので、'next start' で照合すると外れる）。アプリ内ブラウザを使う（Edge は使わない）。

• J4: resize_window 1440×900。★測る条件をそろえる: 開いた直後（期間は直近24時間・1ページだけ）・トークンの値は表示していない状態★（ページ送りの「前へ／次へ」は components/ui/Pagination.tsx で触れない約束なので、2ページ以上だと JP/EN で幅が変わる。測る対象に入れない）。DS-002 のモーダルを JP で開き、javascript_tool で [role=dialog] の中の tbody 以外のボタンの getBoundingClientRect() の x・y・幅を控える → 閉じて EN に切り替えて開き直し、同じく測る → ★全ボタンで x・y・幅のずれが 0★（1px 以内は可）。ダーク/ライトでも崩れない。D-Sec ログの表に横スクロールが出ない
• J10: モーダルを開いた直後の GET /api/ds-devices/DS-002/logs が★1回★（read_network_requests で数える）。種類を1つ外すと types= 付きで1回、戻すと types なしで1回
• J12: 開始日 2026-10-19・終了日 2026-10-18 で「開始日は終了日以前にしてください」。EN で英文
• J1: javascript_tool で window.fetch を差し替えて一覧の取得だけ Promise.reject(new TypeError("Failed to fetch")) にし、種類を1つ外す → 「通信に失敗しました。時間をおいて再度お試しください」が出て、一覧が空になる。差し替えを戻して種類を戻すと一覧が出る
• 今までの動き（一覧・絞り込み・0件の表示・全選択と 100MB の警告・エクスポートの fetch 確認・トークンの発行と失効・DS-001 の未接続・編集中は「ログ」が押せない・Esc・Tab・背景のクリック）が変わらない

★J2・J8・J9 は fixtures の画面では起きない★（fixtures の偽制御盤は形の正しい一覧しか返さない）。単体テスト（表R）で確かめ、画面での確認はしない。

7. 既知の罠

1. ★rejectListResult() を failCommand() で代用しない★ — failCommand() は export の指示ならエクスポートを終わらせる。/result に export の id が来たときにエクスポートを壊す（R43‴ が赤になる）
2. ★/result の 400 の応答本文は今の parsed.error のまま★。rejectListResult() の戻り値（not_found など）で 404 や 410 に変えない（制御盤には「本体が悪い」ことだけを返す）
3. ★AbortError の判定は cause.name で行う★。instanceof DOMException だけだと、Node のテスト環境やブラウザの実装差で外れる（E2）
4. ★status 0 をすべて文言にしてしまうと、モーダルを閉じたときの取り消しで、閉じた後に state を触る★（4-23）。E1・E2 が null であること
5. ★J10 で「全種類」を types.length === selectedTypes.size だけで判定しない★ — 種類の一覧が変わった（制御盤の設定が変わった）ときに、知らない key を含む集合を全種類と誤認する。★件数が同じ、かつ types の key を全部含む★で判定する
6. ★J4 で FilterButton に className の引数を足さない★（§8 で触らない約束。入れ物の CSS で包む）
7. ★J9 で touch() の引数を足すと、touch() を呼んでいる箇所（require-agent.ts とテスト）が型エラーになる★。grep -rn "\.touch(" lib app で全部直す（★relay.test.ts に7か所・app/api/ds-devices の route.test.ts に2か所★）。★vitest は型を検査しないので、直し漏れは tsc でしか分からない★
8. ★J7 で total_bytes を1以上にすると、既存のテスト lib/ds-logs/__tests__/validate.test.ts:409（「total_bytes=0・file_count=1（下限）」は通る）が赤になる★。指示書AY 段階7-2 の「0以上」（fake_dwatch.py との差は実害なし）を本書で取り消す。そのテストの期待を R48 に合わせて直し、報告に書く
9. ★J3 の vi.waitFor で偽の時計を進めない★（fake.at() を待ちの中で呼ぶと、タイマーが登録される前に時刻が進み、別の理由で落ちる。routes.test.ts:103-104 のコメントのとおり）
10. ★T-d の zip の名前の順は、zip の中央ディレクトリの順★。並べ替えて比べない（順番も監督の確認値どおり）

8. 共通ルール

• G1〜G4（指示書AZ §2）: API の挙動が変わったら YAML の影響を受ける箇所を全部直す／古い挙動を書いたコメントを残さない（★少なくとも次の全部★: result/route.ts:5 の「状態は変えない」、relay.ts:125 の touch の説明、DeviceLogsModal.tsx:81 の「status 0（取り消し）は null」、lib/ds-logs/validate.ts:305 の「total_bytes は0以上の整数」と :2-3 の見出しの「W1〜W11」（R45〜R48 を足す）、lib/ds-agent/__tests__/relay.test.ts の :2 の「R1〜R43」・:52 の表の R43・:953 のテスト名・:976 のコメントの「状態は変えない（正しい結果を受け取れる）」（★relay を直接呼ぶので緑のままだが、記述が J2 と食い違う★）、lib/ds-agent/require-agent.ts:6（版も入れる）、lib/logger/events.ts:512 の agent_code の説明（result_invalid は D-Watch が付けるコード）。prepared/route.ts:5・fail/route.ts:5 の「状態は変えない」は正しいので直さない）／テストは壊して赤を確かめる／決定の記録にコミット・件数の前後・画面確認（出所つき）・本書と違う判断を書く
• 期待値表（§4）を先にテストにする。数字・順番を変えない。合わないと思ったら実装を変えずに監督に報告
• git add -A 禁止。★ファイルパスを明示してコミットする★（段階ごと）。PR とマージは daichi のレビューの後
• 触らない: components/ui/（FilterButton.tsx を含む）・docs/handoff/指示書AY_*・docs/handoff/設計_制御盤ログの取り出し_*・components/features/errors/ErrorContentPicker.tsx・lib/errors/error-content-label.ts とそのテスト・prisma/・CLAUDE.md・C:\Users\daich\dev\dwatch-log-agent\（制御盤のプログラム。読むだけ）
• DB に書き込まない。:3000 を起動・停止しない

9. 決定の記録（段階6 で docs/decisions.md の D-179 の末尾に足す。★新しい D 番号は取らない★）

- ★点検の指摘の直し（2026-11-05。指示書BJ）★:
  1. ★制御盤から形の崩れた一覧が来たら、ブラウザの一覧をすぐ 502 `agent_error`（`agent_code` `result_invalid`）で終わらせる★（ユーザー回答 2026-11-05「A」）。制御盤には今までどおり 400。指示書AY の段階7-2（502）と表5 R43（状態は変えない）の食い違いは、一覧については段階7-2 を採る。prepared・complete・fail は R43 のまま
     - 却下: B（15秒待って 504「応答がありません」）— 原因が制御盤側の形の誤りだと分からない
  2. 画面は取り消し（`AbortError`）だけ黙り、通信の失敗は文言を出して一覧を空にする
  3. 制御盤の一覧の `key` は1文字以上で `,` を含まず前後に空白が無い・`file_id` は1〜1024文字・prepared（とブラウザ向けの応答・complete）の `total_bytes` は1以上（指示書AY 段階7-2 の「0以上」を取り消す）
  4. チャンクの POST が保留中に次のチャンクが来たら `chunk_out_of_order` でエクスポートを失敗にする（並列送信は約束違反。孤立したタイマーで後から落ちるのを防ぐ）
  5. 接続のイベントの版は認証の時点で `X-Agent-Version` から入れる
  6. モーダルを開いたときの一覧の問い合わせは1回（全種類のときは `types` を付けない）。制御盤に種類が無いときは「種類を1つ以上選んでください」を出さない。JP/EN でモーダルのボタンの位置と幅を動かさない（期間・並べ替え・トークンのボタンを固定幅に）
  6b. 一覧が `agent_error` で失敗したときは見出しを「接続中」にする（制御盤は結果を返している）
  7. ★残したもの★: `eslint-disable` が2行（指示書AY 4-19 は1行。どちらも `set-state-in-effect` で実害なし）・段階11-1 の grep がテストのファイル（スパイと `mkdtemp`）と型のコメント（「`validation_error` は足さない」）に当たる（指示書AY の grep の書き方の問題。テストが必要とする記述）・種類を素早く切り替えたときに制御盤への一覧の依頼が溜まりうる（推測。待ち行列5件を超えると 429。実機で起きたら直す）
  8. ★実装の記録★: コミット／テスト件数（前 169ファイル・4,260件 → 後）／fixtures の画面確認（当方の fixtures 由来）／本書と違う判断