指示書AX — D-Sec アラートを robot_error_reports から読み、編集モードで対応状況と備考を更新できるようにする（＋清掃詳細ログの 11px 横スクロールを消す）

日付: 2026-10-19 / 担当: Cursor（または監督が指名する実装担当）/ 基点: develop 64c4079 前提: TeamWorks 第11回 P-8・P-10（docs/handoff/TeamWorks回答_第11回_20261005.md:45-60。D-158 docs/decisions.md:12523 以降）/ 第10回 N-5（docs/handoff/TeamWorks回答_第10回_20261002.md:100-112。error_type の値）/ D-091 項3（セキュリティ無効はアラートではない。docs/decisions.md:3510-3551）/ D-105（error_id は string・Number() に通さない。:5442 以降）/ D-160（エラー一覧。:12612）/ D-161・D-165（対応状況はプルダウン・編集モードでまとめて保存。:12647 / :12706）/ D-172（serial_number の拡張待ち → 当面 db pull しない。:12807）/ D-178（詳細ログの事前チェック2列。:12901）/ 指示書AT（4カラム UPDATE）/ 指示書AU 段階0-4（robot_error_reports は select で読む）/ 指示書AW（エラー一覧）/ CLAUDE.md §3・§4.7・§4.8・§6・§7・§9.3・§9.4・§9.6

★ユーザー決定（2026-10-19。§2 の U1〜U8）と監督の設計判断（§2 の D1〜）は確定仕様。変えないこと★（CLAUDE.md §0-1）。 ★期待値表（§3）の表1〜表4 は正。変えないこと★（CLAUDE.md §0-2）。表1 の R1〜R7・R11 は監督確定、R8〜R10・R12・R13・表2・表3 は本書で導き ★監督が正とした（監督判断 2026-10-19。§11 Q5）★。 ★表5（削除済みの施設・清掃エリア。U8）は本書で U8 から導いたもの。監督が確認した（§11 Q9。監督判断 2026-10-19）★。 ★§11 のユーザーへの質問（Q1〜Q4）はすべて確定し、本文に反映済み★（Q4 は 2026-10-19 のユーザー決定 U8 で確定。暫定だった D12 は書き直した）。残るのは監督の確認 Q9（表5）だけ。

★行番号はすべて 2026-10-19 の develop 64c4079 で確かめたもの★。進んでいたら関数名・文で探し直すこと（特に lib/db/index.ts・lib/types/index.ts・d-watch-api.yaml・scripts/seed-local-db.ts）。

★docs/decisions.md と CLAUDE.md は、本書の作成時点で別のセッションが未コミットの編集をしている（D-179）★。 本書の実装で docs/decisions.md に足すのは ★D-180 の追記だけ★（§13 の下書き）。★D-179 の部分・CLAUDE.md には触らない★（CLAUDE.md は監督が直す）。

0. 何をするか

★変えないもの★: D-Sec ログ（/ds-logs。dsDevices()＝controls ＋ control_reports）／エラー一覧（/errors）の挙動・PATCH /errors/{error_id}/status の挙動（★U8 の「削除済みの施設・清掃エリアの行を外す・404 にする」を除く。ルートのコードは変えない — 404 は db.errorReportById() が null を返すことで出る★）／施設名・分類の解決が deleted_at で絞らないこと（★罠7★）／ アラート（/alerts）・PATCH /prechecks/{id}/status／lib/db/robot-error-write.ts（書いてよい列）／lib/prechecks/edit-drafts.ts の中身／ ダッシュボードのセキュリティバナーのコード（computeSecurityBanner()。§2 D4）／prisma/schema.prisma（db pull しない。D-172）。

1. 背景

• いまの prismaSource.dsAlerts()（lib/db/index.ts:1967-1996）は ★control_error_histories（＋ controls / facilities / sections）を読む★。 alert_type は固定で "disconnected"、device_serial = controls.serial_number、detected_at = occurred_at、 resolution_status は resolutionStatusFromControlErrorStatus()（lib/db/ds-status.ts:36-49。0/1/2 → pending / in_progress / done、他は例外）、memo = comment。 ★アプリで control_error_histories を読むのはここだけ★（書くのは scripts/seed-local-db.ts:1160-1182 のシードだけ）。
• TeamWorks の回答:
  • ★第11回 P-10 = A★: ★robot_error_reports を正とする。D-Security のアラートも対応状況の更新もこちら。control_error_histories は読まない★（D-158 の表の P-10 行）。
  • ★第11回 P-8★: 制御盤のエラー＝robot_id NULL・serial_number が制御盤の SN／セキュリティと清掃開始失敗＝robot_id NULL・serial_number が 0（error_type で見分ける）／施設は行の facility_id・section_id（d = A）。
  • ★第10回 N-5★: error_type は D-S_CONTROL_FAILURE（error_detail "no regular report from the D-S control."）と SECURITY_ON（"security is enabled."）。
• ★ステージングの実データ（2026-10-19 監督の SELECT。先方投入）★: robot_error_reports 16行。うち robot_id NULL が9行 ＝ D-S_CONTROL_FAILURE 3行（シリアル DFAS010001 / DFAS010005 / DFAS010002。status 0 が2行・2 が1行）、SECURITY_ON 5行（シリアル ---）、NOT_STARTED 1行（シリアル ---）。
  • ★16行すべて errored_at が NULL★ → 検知時刻は ★errored_at ?? created_at★ でないと出せない（いまの D-Sec は occurred_at を読むので、切り替え後は既存の detectedAtFromError() を使う）。
  • ★error_id 1000004 は、シリアル DFAS010001 が施設2の制御盤なのに、行の facility_id / section_id は 3★（§12 申し送り1）。
  • ★セキュリティ・清掃開始失敗のシリアルは実データでは ---★（P-8 の回答の 0 ではない）。fixtures（lib/fixtures/error-reports.ts:179-215）と docs/fixtures.md:514-534 は '0' のまま。
• いまの D-Sec 画面（components/features/ds-alerts/DsAlertsScreen.tsx）は表示だけ。PATCH /ds-alerts/{id}/status は ★YAML（d-watch-api.yaml:1486-1511）にだけあり、実装されていない★（app/api/ds-alerts/route.ts:7-9）。
• ★既存の不具合（本書で一緒に消える）★: D-Sec 画面の t("未対応") は、EN で ★"Unsupported"★ と出る（lib/i18n.ts:182 は対応機種バッジ用の訳。キーが衝突している）。§2 U5（文言をエラー一覧に揃える。ユーザー確定）で消える。

2. 決定（実装担当は従うこと）

2-1. ユーザー決定（2026-10-19。確定。U5〜U8 は §11 Q1〜Q4 の回答）

2-2. 監督の設計判断（確定。本書の判断だった D9・D10 と段階6 のシードも監督判断 2026-10-19 で確定。§11 Q6〜Q8）

D8 の理由（語彙を揃えるか、別の変換を作るか）

★書き換えは型エラーで漏れなく見つかる。一方、案B の「2つ目の変換」は型では見つからない食い違いの温床★なので、案A を採る。 ★画面の文言（「未対応」か「未解消」か）は語彙とは別の問題★ — こちらもエラー一覧に揃えることでユーザー確定（§2 U5）。

2-3. 本書の暫定

★ユーザー確認待ちの暫定は無い★。旧 2-3 の U5 は確定、U6 は撤回（そのまま残す）、D12 は U8 で確定して書き直した。 ★表5（U8 から導いた期待値）も監督が確認済み（§11 Q9。2026-10-19）★。

3. ★期待値表（正）★

表1（D-Sec アラートに出るか・出たときの値。dsAlertsFromErrorRows()）

★R1〜R7・R11 は §2 のユーザー決定・監督判断から直接決まる（監督確定）★。★R8〜R10・R12・R13 は本書で導き、監督が正とした（監督判断 2026-10-19。§11 Q5）★。

並び順: detected_at の降順、同値は id の昇順（文字列）。

★テストの書き方の注意★:

• R8・R9 は ★Prisma 経路のルートテストで、スタブの findMany が「SQL のように ci・PAD SPACE で当ててしまう」★形にして返す（＝ where を無視して全行返してよい）。そのうえで ★応答に出ない★ことを確かめる。純粋関数の単体テストでも同じ行を入れる
• R10 は単体テストで「例外にならず外れる」、ルートテストで「/api/ds-alerts も /api/dashboard も200」を確かめる
• robot_id NULL の行は ★guardNullRobotId()（lib/db/__tests__/robot-error-null-guard.ts）をスタブに入れる★（robot_id / robot を読むと落ちる）
• 日時は +09:00 付きの ISO 文字列から toDbJst(new Date(...)) で DB の壁時計値を作る（エラー一覧のテストと同じ）
• 設定値は ★D_SEC_ALERT_ERROR_TYPES[0] から読む★。R8・R9 の「わざと違う綴り」は直書きする（コメントで理由を書く）

表2（GET /ds-alerts のパラメータ・summary。★本書で導き監督が正とした（監督判断 2026-10-19。§11 Q5）★）

入力は表1 の R1〜R4・R11〜R13（出る7行。status は R1・R4・R11・R12・R13 が 0、R2 が 1、R3 が 2）と R5〜R10（出ない6行）。

表3（画面の保存の純粋関数。★本書で導き監督が正とした（監督判断 2026-10-19。§11 Q5）★）

dsAlertWithResolution(row, updated)（lib/ds-alerts/edit.ts。新規）と adjustDsAlertSummary(summary, before, updated)（同）:

表4（画面の文言。★§2 U5・U6。ユーザー確定 2026-10-19★）

表5（削除済みの施設・清掃エリア。U8・D12。★本書で導いたもの。§11 Q9 で監督が確認済み（2026-10-19）★）

「施設」「清掃エリア」は行の facility_id / section_id の先（facilities / sections）。「削除」は deleted_at が NULL でないこと。

★テストの書き方の注意★:

• Prisma 経路のスタブは ★where の facility.deleted_at / section.deleted_at の条件も評価する★形と、★where を無視して全行返す★形の両方で確かめる（後者で ★純粋関数側の isVisibleErrorRow() が外す★ことを見る。D2 と同じ考え方）
• PATCH の404 は ★db.errorReportById() が null を返すことで出る★。★updateMany が呼ばれないこと・db.write が出ないこと★を確かめる（存在しない id の404 と同じ扱い）
• 削除の日時は ★過去の日時★を入れる（toDbJst(new Date("2026-10-01T10:00:00+09:00")) 等）。★「未来の日時なら生きている」とはしない★（D12。NULL か否かだけ）

4. ★落とし穴（全段階で読むこと）★

段階0 — 着手前

1. ★develop で作業する★（.claude/worktrees/ の中ではない。ワークツリーは main 基点で古い）。git pull で最新にし、64c4079 以降であることを確かめる。
2. git status を控える。★CLAUDE.md・docs/decisions.md（D-179）・docs/handoff/TeamWorks確認事項_第13回_*・docs/handoff/回答待ち一覧_*・docs/handoff/pdf/*.py は他のセッションの作業★。触らない・コミットに含めない。
3. npx prisma generate → npx tsc --noEmit -p . → npm test が通ることを確かめ、★テストの件数を記録する★。通らなければ着手前に報告。
4. ★Next.js は版が新しい★。画面・ルートを書く前に node_modules/next/dist/docs/ の該当の項を読む（CLAUDE.md 末尾）。
5. ★§11 Q5〜Q8 は監督判断（2026-10-19）で確定済み★。★表5（U8）も §11 Q9 で監督が確認済み（2026-10-19）★。

段階1 — 期待値表をテストにする（実装より先）

★この時点ではテストが落ちる（関数・型が無い）のが正しい★。コミットはテストだけで1つ（「テストだけ。この時点では落ちる」と明記）。

1. ★lib/db/__tests__/ds-alert-mapping.test.ts（新規）★: 冒頭コメントに表1 を写し「R1〜R7・R11 は監督確定、R8〜R10・R12・R13 は指示書AX で導き監督が正としたもの（2026-10-19）」と書く。
   • isDsAlertRow(): R1〜R13 の出る／出ない（it.each）
   • dsAlertFromErrorRow(): R1〜R4・R11 の各値（alert_type / device_serial / facility_id / facility_name / section_name / detected_at / resolution_status / responded_at / resolved_at / note）。★R4 は created_at が detected_at に入る★
   • dsAlertsFromErrorRows(): 13行を入れて7行が出る・並びは呼び出し側（sortDsAlerts()）に任せるので ★順は問わない★（toEqual(expect.arrayContaining(...)) と件数）
   • dsAlertWhere(): { error_type: { in: [...D_SEC_ALERT_ERROR_TYPES] }, status: { in: [0,1,2 を robotErrorStatusFromResolutionStatus から作ったもの] }, ...ERROR_ROW_VISIBLE_WHERE } と toEqual（★期待値も変換関数から作る。直書きしない★。可視性は U8・段階2-7）
2. ★lib/ds-alerts/__tests__/query.test.ts（直す）★:
   • row()（:11-25）を新しい型に（id: "1"・resolution_status: "unresolved"・note: null）
   • status の選択肢の422の文言を open / all / resolved に（:67-77）。★status=done は422★（表2 A4）
   • filterDsAlertsByStatus（:168-197）: open = 未解消＋対応中／resolved = 解消のみ／all。「type=disconnected & status=done で0件」のテスト（:187）は status=resolved に読み替え、★「fixtures の再現条件」という説明は消す★（fixtures の意図的な0件は無くなる。段階3）
   • sortDsAlerts（:199-217）: 同値のときの ★文字列の辞書順★（"10" が "9" より先）を足す
   • summarizeDsAlerts（:219-233）: キーを unresolved / in_progress / resolved に
3. ★lib/ds-alerts/__tests__/edit.test.ts（新規）★: 表3 S1〜S6
4. ★lib/dashboard/__tests__/aggregate.test.ts（直す）★: alert()（:72-91）を新しい型に（id: String(seq)・resolution_status は PrecheckStatus・resolved のとき resolved_at・note: null）。computeSecurityBanner のテスト（:300-340）は "pending" → "unresolved"、"done" → "resolved"。not.toHaveProperty("memo") は ★"note" にも当てる★（両方書いてよい）
5. ★lib/db/__tests__/robot-error-select.test.ts★: SELECTS（:19-27）に ROBOT_ERROR_DS_ALERT_SELECT を足す
6. ★lib/db/__tests__/ds-status.test.ts★: resolutionStatusFromControlErrorStatus / controlErrorStatusFromResolutionStatus / 往復の describe（:33-70）を削る（D14）。connectionStatus* の2つは残す
7. ★lib/db/__tests__/error-report-visibility.test.ts（新規）★: isVisibleErrorRow() — 両方生きている → true／施設だけ削除 → false／清掃エリアだけ削除 → false／両方削除 → false（表5 V1〜V7 の可視性の列）。ERROR_ROW_VISIBLE_WHERE が { facility: { deleted_at: null }, section: { deleted_at: null } } と toEqual
8. ★lib/db/__tests__/error-report-mapping.test.ts（直す）★: ★行の組み立てに facility.deleted_at / section.deleted_at（既定 null）を足す★（型が要求する）。errorReportKeyFromRow() の visible が表5 どおり。★errorReportListWhere() の期待値に ERROR_ROW_VISIBLE_WHERE の2キーが入る★（旧「既定 → status だけ」は「status と施設・清掃エリアの可視性」に直す。facility_ids / 期間のケースも同じ2キーを含む）。★AW の表1 E1〜E9 の期待値そのものは変えない★（全行が生きている）
9. ★lib/error-reports/__tests__/query.test.ts（直す）★: キーの組み立てに visible: true を足す（型）。★visible: false のキーは既定でも include_resolved=true でも外れ、total に数えない★（表5 V2・V3・V7）
10. lib/db/__tests__/ds-alert-mapping.test.ts（1 の続き）: 表5 V4〜V7 の D-Sec 列。dsAlertWhere() の期待値に ERROR_ROW_VISIBLE_WHERE の2キー
11. lib/db/__tests__/robot-error-select.test.ts: ★ROBOT_ERROR_LIST_KEY_SELECT / ROBOT_ERROR_LIST_ROW_SELECT / ROBOT_ERROR_DS_ALERT_SELECT が facility.select.deleted_at と section.select.deleted_at を含む★ことを足す（可視性の判定に要る列の取り忘れを防ぐ）

段階2 — 設定・型・純粋関数

2-1. lib/config/index.ts — 設定値を1つ足す

PRECHECK_NOTE_MAX_LENGTH（:628）の近くに:

/**
 * D-Sec アラートとして出す `robot_error_reports.error_type` の値（指示書AX D1。D-180）。
 * ★完全一致（JS の `===`）で比べる★ — SQL の `IN` は写し（DB の照合順序は大小文字・末尾の空白を区別しないため）。
 * ★`SECURITY_ON` は入れない★（ユーザー判断 2026-10-19。D-091 項3「セキュリティが無効であっても異常ではない」）。
 * ★`NOT_STARTED`（清掃開始失敗）も入れない★（ロボット側の出発失敗。同日のユーザー判断）。
 * 値の出所: TeamWorks 第10回 N-5（`D-S_CONTROL_FAILURE` = "no regular report from the D-S control."）。
 */
export const D_SEC_ALERT_ERROR_TYPES: readonly string[] = ["D-S_CONTROL_FAILURE"];

★配列にする★（後から値を足せる）。★as const にしない★（includes(row.error_type) で string を渡すため）。

2-2. lib/types/index.ts（:1033-1058）

• ★DsAlertStatus を削除★。DsAlert.resolution_status: PrecheckStatus（D8）
• DsAlertStatusFilter = "open" | "all" | "resolved"（D10）。docstring「open = unresolved + in_progress」
• DsAlert:
  • id: string — docstring「robot_error_reports.error_id（★string のまま。Number() を通さない。D-105★）」
  • device_serial — 「robot_error_reports.serial_number の生値（D-077）。制御盤の SN」
  • section_name — ★旧 docstring の「実DB上の取得元が不明なため fixtures では暫定のダミー値」を消し★、「行の section_id の清掃エリア名」に
  • detected_at — 「errored_at ?? created_at（detectedAtFromError()）」
  • ★memo → note★（D9）
  • alert_type — 「★DB からは disconnected しか出ない★（security_off は互換のため残す。D-180）」
• DsAlertType / DsAlertTypeFilter は変えない

2-3. lib/db/robot-error-select.ts — 定数を1つ足す（末尾）

/**
 * D-Sec アラート（`dsAlertFromErrorRow()`。`dsAlerts()`）に要る列（指示書AX）。
 * ★`section` は清掃エリア名だけ★（D-Sec のカードに出す）。★`robot_id` / `robot` を足さない★（D-Sec の行は全部 `robot_id` NULL）。
 * ★`clean_timetable_id` は使わないが、select の共通テスト（紐づけのキーを含む）のために読む★
 */
export const ROBOT_ERROR_DS_ALERT_SELECT = {
  error_id: true,
  clean_timetable_id: true,
  serial_number: true,
  facility_id: true,
  facility: { select: { facility_name: true, deleted_at: true } },   // deleted_at は可視性（U8・段階2-7）
  section: { select: { section_name: true, deleted_at: true } },
  error_type: true,
  errored_at: true,
  created_at: true,
  status: true,
  responded_at: true,
  resolved_at: true,
  comment: true,
} as const satisfies Prisma.RobotErrorReportSelect;

★ROBOT_ERROR_LIST_ROW_SELECT の docstring「section を足さない」はその定数についての話なので、そちらは変えない★。

2-4. lib/db/ds-alert-mapping.ts（新規）— ★純粋関数のみ★（lib/db/error-report-mapping.ts と同じ作法）

/** `ROBOT_ERROR_DS_ALERT_SELECT` の結果がそのまま入る形 */
export interface DsAlertRowSource extends PrecheckDetectedAtSource {
  error_id: string;
  serial_number: string;
  facility_id: bigint;
  facility: { facility_name: string; deleted_at: Date | null };
  section: { section_name: string; deleted_at: Date | null };
  error_type: string;
  status: number;
  responded_at: Date | null;
  resolved_at: Date | null;
  comment: string | null;
}

/** ★D-Sec アラートの対象か（正）★: `error_type` が `D_SEC_ALERT_ERROR_TYPES` に `===` で一致し、`status` が 0/1/2 */
export function isDsAlertRow(row: Pick<DsAlertRowSource, "error_type" | "status">): boolean
/** 1行 → `DsAlert`（★`isDsAlertRow()` を通った行だけを渡す★。`status` が 0/1/2 以外なら変換関数が例外） */
export function dsAlertFromErrorRow(row: DsAlertRowSource): DsAlert
/** `rows.filter((r) => isDsAlertRow(r) && isVisibleErrorRow(r)).map(dsAlertFromErrorRow)`（fixtures 版・Prisma 版が共有する1本。可視性は U8） */
export function dsAlertsFromErrorRows(rows: readonly DsAlertRowSource[]): DsAlert[]
/** SQL 側の写し: `{ error_type: { in: [...D_SEC_ALERT_ERROR_TYPES] }, status: { in: dsAlertStatusCodes() }, ...ERROR_ROW_VISIBLE_WHERE }` */
export function dsAlertWhere(): Prisma.RobotErrorReportWhereInput

• isDsAlertRow(): ★D_SEC_ALERT_ERROR_TYPES.includes(row.error_type)★（Array.prototype.includes は === 相当。★toUpperCase() / trim() で緩めない★）かつ ★dsAlertStatusCodes().includes(row.status)★
• 状態のコード: (["unresolved", "in_progress", "resolved"] as const).map(robotErrorStatusFromResolutionStatus)（★0/1/2 を直書きしない★。非公開の関数 dsAlertStatusCodes() にまとめてよい）
• dsAlertFromErrorRow():
  • id: row.error_id（★string のまま★）／alert_type: "disconnected"／device_serial: row.serial_number（★そのまま★）
  • facility_id: Number(row.facility_id)／facility_name: row.facility.facility_name／section_name: row.section.section_name
  • detected_at: jstIsoFromDb(detectedAtFromError(row))
  • resolution_status: resolutionStatusFromRobotErrorStatus(row.status)
  • responded_at / resolved_at: null はそのまま、それ以外 jstIsoFromDb()／note: row.comment
  • ★errorReportItemFromRow()（lib/db/error-report-mapping.ts:136）と同じ書き方で揃える★（日時・BigInt の扱い）
• 冒頭の docstring に: 根拠（P-10 = A・U1〜U3・D1〜D3）、★control_error_histories は読まない★、★robot_id を読まない★、★security_off はここからは出ない（D4）★

2-5. lib/ds-alerts/query.ts

• STATUS_FILTERS（:15）を ["open", "all", "resolved"] に
• filterDsAlertsByStatus()（:96-111）: open → resolution_status !== "resolved"／resolved → === "resolved"／all
• sortDsAlerts()（:113-120）: 同値は ★a.id < b.id ? -1 : a.id > b.id ? 1 : 0★（D11）。docstring に「id は string。辞書順」
• DsAlertSummary（:122-126）: { unresolved; in_progress; resolved }／summarizeDsAlerts()（:136-）も同じキーで数える
• ★TYPE_FILTERS と filterDsAlertsByType() は変えない★（D4）

2-6. lib/ds-alerts/edit.ts（新規）— ★純粋関数のみ★（画面の保存で使う。表3）

/** PATCH /errors/{error_id}/status の応答（`ErrorReportItem`）を `DsAlert` に戻す。★4項目だけ差し替え★。id が違えば例外 */
export function dsAlertWithResolution(row: DsAlert, updated: ErrorReportItem): DsAlert
/** 保存で状態が変わった行の分だけ `summary` を付け替える（旧状態 −1・新状態 +1）。★入力を書き換えない★ */
export function adjustDsAlertSummary(
  summary: DsAlertSummary,
  before: readonly DsAlert[],
  updated: ReadonlyMap<string, DsAlert>
): DsAlertSummary

before は保存前の画面の行（id で updated と突き合わせる）。updated に無い行・状態が同じ行は数えない（表3 S4・S6）。

段階1 のテストのうち純粋関数のものが通ること。コミット。

2-7. 削除済みの施設・清掃エリアの行を外す（U8・D12）— エラー一覧と D-Sec の共通部品

lib/db/error-report-mapping.ts（★純粋関数のみのまま★）に足す:

/** 可視性の判定に要る列（`facility` / `section` の `deleted_at`） */
export interface ErrorRowVisibilitySource {
  facility: { deleted_at: Date | null };
  section: { deleted_at: Date | null };
}
/**
 * ★削除済み（論理削除）の施設・清掃エリアの行は見せない★（ユーザー決定 2026-10-19「削除済みのものは表示する必要がないので、
 *   エラー一覧からもD-sec一覧からも消してください」。指示書AX U8・D12。D-180）。★`deleted_at` が NULL でなければ削除済み（日時によらない）★。
 * ★これが正★。SQL の `ERROR_ROW_VISIBLE_WHERE` は写し（fixtures はこちらしか通らない）。
 * ★施設名・分類の解決は `deleted_at` で絞らない（罠7）★ — この関数は `robot_error_reports` の行の可視性だけを決める
 */
export function isVisibleErrorRow(row: ErrorRowVisibilitySource): boolean {
  return row.facility.deleted_at === null && row.section.deleted_at === null;
}
/** SQL 側の写し（`errorReportListWhere()` と `dsAlertWhere()` に混ぜる） */
export const ERROR_ROW_VISIBLE_WHERE = {
  facility: { deleted_at: null },
  section: { deleted_at: null },
} as const satisfies Prisma.RobotErrorReportWhereInput;

• ★ErrorReportKeySource★ に ErrorRowVisibilitySource を足し（extends）、★ErrorReportKey に visible: boolean★ を足す。errorReportKeyFromRow() が visible: isVisibleErrorRow(row) を入れる
• ★ErrorReportRowSource★ の facility を { facility_name: string; deleted_at: Date | null } に、★section: { deleted_at: Date | null } を足す★
• ★errorReportListWhere()★ の戻りに ★...ERROR_ROW_VISIBLE_WHERE★ を混ぜる（status の次。docstring に U8）
• ★filterSortErrorReportKeys()（lib/error-reports/query.ts:151-167）★ の filter の先頭に ★if (!key.visible) return false;★（★絞り込みの正★。meta.total もこれで正しくなる）
• ★lib/db/robot-error-select.ts★:
  • ROBOT_ERROR_LIST_KEY_SELECT に ★facility: { select: { deleted_at: true } }・section: { select: { deleted_at: true } }★
  • ROBOT_ERROR_LIST_ROW_SELECT の facility を ★{ select: { facility_name: true, deleted_at: true } }★ に、★section: { select: { deleted_at: true } } を足す★。docstring の「★section を足さない★」は ★「section は deleted_at だけ（U8）。robot_id / robot は足さない」★ に書き換える（元の理由は robot_id が NULL の行で落ちることで、section は無関係）
  • ROBOT_ERROR_DS_ALERT_SELECT は 2-3 のとおり（deleted_at 入り）
• ★lib/db/ds-alert-mapping.ts★: dsAlertsFromErrorRows() は isDsAlertRow(r) && isVisibleErrorRow(r)、dsAlertWhere() は ...ERROR_ROW_VISIBLE_WHERE を混ぜる（2-4 のとおり）
• ★PATCH /errors/{error_id}/status のルート（app/api/errors/[error_id]/status/route.ts）は変えない★ — 実在確認（:126 の db.errorReportById()）が null を返せば既存の404の分岐に入る

段階3 — データ層（fixtures・Prisma）

3-1. fixtures の行 — lib/fixtures/error-reports.ts

1. FixtureErrorReportRow（:34-36）に ★section: { section_name: string; deleted_at: Date | null }★ を足す（★全行に持たせる★。実DBでも section_id は NOT NULL）。robotError()（:85-106）の既定は { section_name: "1F売り場", deleted_at: null }。★facilityOf()（:64-68）が返す facility にも deleted_at: null を足す★（U8）
2. ★セキュリティ・清掃開始失敗のシリアルを実データに揃える★: FX-ERR-08（:179-188）と FX-ERR-11（:206-215）の serial_number: "0" → ★"---"★。 ★定数 SERIAL_NOT_APPLICABLE = "---" を置き、コメントに「ステージングの実データ（2026-10-19 監督の SELECT・先方投入）。P-8 の回答は 0 だが実値は ---（§12 申し送り2）」★
3. ★D-Sec の行を足す★（FX-ERR-12〜FX-ERR-17。robot_id: null・error_type: D_SEC_ALERT_ERROR_TYPES[0]・error_level: "CRITICAL"（N-5））。★シリアルは controlPanelSerialOf() で引く★（直書きしない）:| id | 施設（顧客） | シリアル | status | errored_at / created_at | その他 | 表1 | |---|---|---|---|---|---|---| | FX-ERR-10（既存） | 1（1） | 施設1の制御盤（DS-001） | 0 | 前日 22:45 / 22:46 | section 1F売り場 | R1 | | FX-ERR-12 | 11（2） | 施設11の制御盤 | 0 | ★errored_at NULL★ / 当日 02:55 | ★clean_timetable_id NULL★・section 2F衣料品 | R4・R13 | | FX-ERR-13 | 5（1） | 施設5の制御盤 | 1 | 前日 23:10 / 23:11 | responded_at 当日 09:05・備考「回線業者に確認中」・section 1Fレジ前 | R2 | | FX-ERR-14 | 4（2） | 施設4の制御盤 | 2 | 前日 03:55 / 03:56 | responded_at 前日 08:40・resolved_at 前日 09:15・備考「正常復帰を確認」・section B1食品 | R3 | | FX-ERR-15 | 10（3） | 施設10の制御盤 | 2 | 2日前 02:00 / 02:01 | responded_at / resolved_at あり・備考「正常復帰を確認」 | R3 | | FX-ERR-16 | ★3（1）★ | ★施設2の制御盤★ | 0 | 当日 01:30 / 01:31 | ★シリアルと施設が食い違う★（ステージング 1000004 の形） | R11 | | FX-ERR-17 | 8（1） | 施設8の制御盤 | 1 | ★当日 01:30（FX-ERR-16 と同時刻）★ / 01:32 | responded_at あり | R12（"FX-ERR-16" が先） |
   • clean_timetable_id は FX-ERR-12 以外 TT_MAIN_A / TT_MAIN_B のどちらか（P-9: 制御盤の行にも予定 id が入る）
   • ★施設は顧客1と顧客1以外の両方にまたがること★（app/api/__tests__/master-filter.test.ts:194-201 / :364-380 が「customer_id=1 で真に減る」を見ている）
   • ★R8〜R10（綴り違い・status 3）は fixtures に入れない★（単体テストとルートテストのスタブにだけ置く。fixtures はデモにも使うので）
4. ★削除済みの施設・清掃エリアの行を2つ足す★（U8。表5。どちらも status 0 — ★可視性が無ければ既定で出るはずの行★にして、外れることを確かめる）:| id | 内容 | 施設 | 清掃エリア | 表5 | |---|---|---|---|---| | FX-ERR-18 | ロボットのエラー（EmergencyStop・robot_id あり） | ★削除済みのダミー施設★（id 99・名前「削除済みテスト施設（ダミー）」・deleted_at 過去の日時）。★facilities（lib/fixtures/facilities.ts）には足さない★（施設一覧・分類・他の画面に出さないため）。専用の小さな関数で作る（facilityOf() を通さない） | 生きている | V2 | | FX-ERR-19 | D-S_CONTROL_FAILURE（robot_id NULL・施設2の制御盤のシリアル） | 施設2（生きている） | ★削除済み★（section_name 「旧2F売り場（削除済み）」・deleted_at 過去の日時） | V6（status は 0 にする） |
   • ★施設2の他の行（FX-ERR-04・05）の清掃エリアは生きている★ので出続ける（表5 V9）
   • 実在の店名を使わない（CLAUDE.md §7）
5. ファイル冒頭の docstring の件数・説明を直す（★errorReportRows は19行。そのうち見える行は17行（既定（未解消・対応中）14行・「解消済みも表示」17行）★、D-Sec は7行（FX-ERR-19 は削除済みの清掃エリアなので出ない））

3-2. lib/fixtures/ds-alerts.ts を削除し、lib/fixtures/index.ts:19 の export * from "./ds-alerts"; を消す

3-3. DataSource と2つの実装 — lib/db/index.ts

• ★DataSource.dsAlerts()（:371）の契約は変えない★（引数なし・Promise<DsAlert[]>。/dashboard も呼ぶ）。docstring に「robot_error_reports の D_SEC_ALERT_ERROR_TYPES の行（指示書AX）。★並べ替え・絞り込み（type / status / 分類）はルート側★」
• ★fixtures 版★（:683-685）:

  async dsAlerts() {
    // ★Prisma 版と同じ純粋関数★（D13）。★エラー一覧の上書き表を反映してから作る★ —
    //   `PATCH /errors/{error_id}/status` で書いた対応状況が D-Sec にも出る（U4）
    return dsAlertsFromErrorRows(errorReportRows.map(withFixtureErrorReportOverride));
  },

• ★Prisma 版★（:1954-1996。docstring ごと置き換える）:

  async dsAlerts() {
    const { getPrisma } = await import("./prisma");
    const prisma = await getPrisma();
    // ★SQL は写し（`error_type IN`・`status IN`）。正は `dsAlertsFromErrorRows()` の `===`（D2・D3）★
    const rows = await prisma.robotErrorReport.findMany({
      where: dsAlertWhere(),
      select: ROBOT_ERROR_DS_ALERT_SELECT,
    });
    return dsAlertsFromErrorRows(rows);
  },

  ★旧 docstring の「security_off は返さない理由（security_statuses に列が無い）」は消し★、新しい理由（U1。D-091 項3）に書き換える。
• import の整理: dsAlerts（fixtures。:60）と resolutionStatusFromControlErrorStatus（:168）を消す。ROBOT_ERROR_DS_ALERT_SELECT / dsAlertWhere / dsAlertsFromErrorRows を足す
• ★lib/db/index.ts:15 付近の冒頭コメント「書き込んでよいのは robot_error_reports / control_error_histories の…」は変えない★（権限の説明として正しい）

3-3b. エラー一覧の可視性（U8）— lib/db/index.ts

• ★fixtures 版 errorReports()（:647-656）★: 変えなくてよい（errorReportKeyFromRow() が visible を入れ、filterSortErrorReportKeys() が外す）。★確かめるだけ★
• ★fixtures 版 errorReportById()（:658-667）★: 行が見つかっても ★!isVisibleErrorRow(row) なら null★（＝ PATCH は404）
• ★Prisma 版 errorReports()（:1743-1783）★: 1段目の where は errorReportListWhere()（2-7 で可視性入り）・select は ROBOT_ERROR_LIST_KEY_SELECT（deleted_at 入り）のまま。コードの変更は無いはず
• ★Prisma 版 errorReportById()（:1785-1806）★: report.error_id !== id の null の直後に ★if (!isVisibleErrorRow(report)) return null;★（4-21）。コメントに U8
• ★errorReportItemsInPageOrder()（:540-556）★: ★見えない行も「消えた行」と同じく飛ばす★（1段目と2段目の間に施設が削除された場合。meta.total は1段目のまま — 4-15 と同じ扱い）
• ★updateErrorReportColumns() は変えない★（存在・可視性はルートが書く前に errorReportById() で確かめる）

3-4. 件数が変わるテスト・資料を直す（★エラー一覧の fixtures が 11 → 19 行。見える行は17★）

• lib/db/__tests__/fixture-error-reports.test.ts: :49-53（17行・FX-ERR-01〜17）／:88・:92（シリアル ---）／:96-97（robot_id NULL は 08・10〜17）／:102-108（既定14・全17）／:120 付近（ページの total）／並びの期待（降順の列）を ★テストを走らせて得た順ではなく、表の時刻から手で導いて★ 書く
• lib/db/__tests__/fixture-error-reports.test.ts の続き: ★errorReportRows は19行（FX-ERR-01〜19）★・robot_id NULL は 08・10〜17・19・★既定14・全17（FX-ERR-18・19 は出ない）★・★db.errorReportById("FX-ERR-18") / ("FX-ERR-19") は null★
• app/api/errors/__tests__/route.fixtures.test.ts: 件数（既定14・全17）。★PATCH /api/errors/FX-ERR-18/status・FX-ERR-19 は404★（表5 V2・V6）
• ★新規 app/api/ds-alerts/__tests__/route.fixtures.test.ts★: fixtures で GET /api/ds-alerts（既定5件・status=all で7件・summary {unresolved:3, in_progress:2, resolved:2}・FX-ERR-08 / FX-ERR-11 / ★FX-ERR-19（削除済みの清掃エリア）★ が出ない）→ ★PATCH /api/errors/FX-ERR-10/status（resolved）→ GET /api/ds-alerts に反映（status=open から消え、summary.resolved が 3）★。beforeEach で resetFixtureErrorReportOverrides()

段階1 の残りのテストが通ること。コミット。

段階4 — API（YAML → ルート）

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

1. /ds-alerts（:1452-1484）の description に:
   • ★取得元は robot_error_reports のうち error_type が D-S_CONTROL_FAILURE の行（完全一致。D-180）★。SECURITY_ON・NOT_STARTED は含まない（エラー一覧 /errors には出る）
   • ★alert_type は DB からは disconnected だけ★。security_off は互換のため enum に残すが出ない
   • 施設は行の facility_id（制御盤のシリアルの所属ではない）／detected_at は errored_at（無ければ created_at）
   • 並び順は detected_at の降順、同値は ★id（error_id）の昇順（文字列の辞書順）★
   • ★対応状況・備考の更新は PATCH /errors/{error_id}/status（同じ行）★
2. status パラメータ（:1469-1475）: enum: [open, all, resolved]／description: open=未解消・対応中 / resolved=解消
3. ★/ds-alerts/{id}/status（:1486-1511）を削除★（D7）
4. DsAlert（:2647-2678）: id: { type: string, maxLength: 50, example: "1000001", description: robot_error_reports.error_id }／alert_type の description に D4／device_serial の example を "DFAS010001"・description「生値（D-077）」／ section_name の description を「行の section_id の清掃エリア名」（★「取得元が未確定で fixtures では暫定のダミー値」を消す★）／detected_at に description／ resolution_status: enum [unresolved, in_progress, resolved]・description「未解消 / 対応中 / 解消」／★memo → note★
5. DsAlertListResponse.summary（:2683-2688）: unresolved / in_progress / resolved
6. security_banner（:308-316）の description に「★/ds-alerts が DB から security_off を返さないため、DB 接続時は常に空配列（D-180）★」を足す

4-2. app/api/ds-alerts/route.ts

• 冒頭コメント（:1-10）の「★対応状況の更新（PATCH /ds-alerts/{id}/status）は今回作らない…★」を ★「対応状況・備考の更新は PATCH /errors/{error_id}/status（robot_error_reports の同じ行。指示書AX D6）。このルートは読むだけ」★ に書き換える
• ★処理の流れは変えない★（parseDsAlertQuery() → 分類の解決と db.dsAlerts() を同じ try → filterRowsByFacilityIds() → summary → type / status → 並べ替え → ページ）。型の変更に追従するだけ

4-3. app/api/dashboard/route.ts

★コードは変えない★（db.dsAlerts() → computeSecurityBanner() のまま。D4）。:189-211 付近に「★DB のデータでは security_off が出ないのでバナーは常に空（指示書AX D4）★」のコメントを1つ足してよい。

4-4. テスト

1. ★app/api/ds-alerts/__tests__/route.test.ts（新規。Prisma 経路）★ — app/api/errors/__tests__/route.test.ts の作法（vi.mock("@/lib/db/use-fixtures", () => ({ USE_FIXTURES: false }))・@/lib/db/prisma のスタブ）:
   • スタブの robotErrorReport.findMany は ★guardNullRobotId() を通し★、★where を無視して全行（表1 の13行）を返す★（＝ SQL が ci・PAD SPACE で余分に当てた状態を再現。D2）
   • ★findMany の引数の where が dsAlertWhere() と toEqual、select が ROBOT_ERROR_DS_ALERT_SELECT★（ルートが別の条件を組み立てていない）
   • 表2 A1〜A7・A9。★R5〜R10 が出ない★・★R11 が施設3で出る★・★R12 の並び★
   • ★controlErrorHistory のスタブを置かない（呼ばれたら落ちる形にする）★ — もう読まないことの証拠
   • 分類（A8）は既存の master-filter.test.ts に任せてよい（fixtures 経路）。★Prisma 経路で施設名・分類を同時に試すと、モックした @/lib/db/prisma の動的 import の罠を踏む★（指示書AW §13-4 #2）。要るなら db.facilityGroupIndex() 等を vi.spyOn で差し替える 1b. ★app/api/errors/__tests__/route.test.ts（直す。Prisma 経路）★: スタブの行に facility.deleted_at / section.deleted_at を持たせ（既存の行は null）、★スタブの where の評価に facility.deleted_at / section.deleted_at の条件を足す★。表5 V1〜V3・V9 の行を足し、★V2・V3 が既定でも include_resolved=true でも出ず meta.total に数えない★、★V8（V2 の施設名で絞る）が0件・200★。★where を無視して全行返すスタブでも V2・V3 が出ない★（純粋関数側で外れる）ことを1件確かめる。★1段目の where が errorReportListWhere() と toEqual★ は既存のまま（可視性が入った戻りと一致） 1c. ★app/api/errors/[error_id]/status/__tests__/route.test.ts（足す）★: findUnique のスタブが ★施設が削除済みの行（V2）・清掃エリアが削除済みの行（V3）・D-Sec の V5★ を返す → ★404（error.code は既存の404と同じ）・updateMany を呼ばない・db.write を出さない★。生きている行（V1・V4）は200（既存） 1d. app/api/ds-alerts/__tests__/route.test.ts（1 の続き）: 表5 V4〜V7。★V5〜V7 は一覧にも summary にも出ない★（where を無視して全行返すスタブで）
2. ★app/api/dashboard/__tests__/route.test.ts★: スタブの controlErrorHistory（:174）を消す（読まないので）。★robotErrorReport.findMany のスタブ（:172）は [] のまま★でよい。★表1 R10（status 3）の行を返しても200★のテストを1つ足す（dsAlerts() がダッシュボードを落とさない証拠。D3）
3. app/api/__tests__/master-filter.test.ts: :364-380 の summary の型とキーを unresolved / in_progress / resolved に。:194-201 は status=all のまま（all は残る）
4. ★既存のテストが無修正で通ること★（★U8 で app/api/errors/** と lib/db/__tests__/error-report-mapping.test.ts・lib/error-reports/__tests__/query.test.ts は行の型の追従と表5 の追加が要るので、このリストから外れる★）: app/api/prechecks/**・lib/prechecks/__tests__/*・lib/db/__tests__/robot-error-write-sql.test.ts・lib/db/__tests__/error-report-mapping.test.ts（★AW の表1 E8 のシリアル '0' はテスト内の行なので変えない★）

YAML → ルート → テストの順でコミット。

段階5 — 画面（/ds-alerts に編集モード）

★見た目と操作はエラー一覧（components/features/errors/ErrorsScreen.tsx・.module.css）から借りる。新しい共通部品は作らない★（指示書AW と同じ考え方）。 ★D-Sec 画面はカードの一覧（表ではない）★なので、カードの中で同じ部品を使う。

5-1. components/features/ds-alerts/DsAlertsScreen.tsx

1. 型の追従: DsAlertStatusFilter は "open" | "all" | "resolved"、EMPTY_SUMMARY は { unresolved: 0, in_progress: 0, resolved: 0 }、バッジの分岐（:294-308）は resolved / in_progress / unresolved
2. 文言（表4。§2 U5）: 数値カード（:141-143）・状態ボタン（:229-261）・バッジを表4 のとおり。★副題（:136）と種別のセレクト（:217-228）・typeFilter の state は ★変えない★（U6。ユーザー判断で残す。「セキュリティ無効」を選ぶと0件になるのは承知のうえ）★。★編集中は種別のセレクトも他の絞り込みと同じく無効にする★（<fieldset disabled> の中に入れる）。カードの「通信断」Pill（:281）は残す
3. 編集モード（エラー一覧の ErrorsScreen.tsx の editing / drafts / rowErrors / saving / beforeunload / canStartEdit / filtersDisabled / startEdit / cancelEdit / saveEdit をそのまま写す）:
   • 見出しの右に ★編集 ／ 編集中は 保存（N件）（N=0 なら 保存、保存中は 保存中…）・キャンセル★（ボタンは固定幅。ErrorsScreen.module.css:53- の .editButton 等を写す）
   • 下書きは ★lib/prechecks/edit-drafts.ts の draftStatus / draftNote / setDraftStatus / setDraftNote / saveDrafts★（DsAlert がそのまま EditableRow になる。D9）
   • 送る関数:

     /** ★書き込みはエラー一覧と同じルート（指示書AX D6）★。応答は ErrorReportItem なので DsAlert に戻す */
     async function sendDsAlertUpdate(row: DsAlert, request: PrecheckStatusUpdateRequest): Promise<DsAlert> {
       const updated = await apiFetch<ErrorReportItem>(`/api/errors/${encodeURIComponent(row.id)}/status`, {
         method: "PATCH",
         headers: { "Content-Type": "application/json" },
         body: JSON.stringify(request),
       });
       return dsAlertWithResolution(row, updated);
     }

   • 保存後: ★成功した行だけ差し替え★、★summary は adjustDsAlertSummary(summary, 保存前の items, updated)★（D15）。★1件でも失敗したら編集モードのまま★、失敗したカードの直下に文言（t(rowError)。サーバーの文言は辞書に無ければ原文）。全部成功なら通常モードへ
   • カードの中身: 通常モードは今のバッジ（★押しても何も起きない★）。編集モードは ★対応状況のプルダウン★（エラー一覧の STATUS_OPTIONS と同じ並び・文言。.statusSelect を写す）と ★備考の textarea★（2行・resize: none・maxLength={PRECHECK_NOTE_MAX_LENGTH}・placeholder t("備考を入力")）。 ★通常モードの備考は今の memoLine の位置に item.note を出す★（空なら出さない＝今と同じ）
   • ★解消のときはバッジの下に解消日時★（item.resolution_status === "resolved" かつ ★保存済みの値で判定★。エラー一覧と同じ）
   • ★変えたカードの目印★（ErrorsScreen.module.css の .rowChanged と同じ色をカードの背景に）
   • ★編集中は絞り込み（分類のセレクト・状態ボタン）とページ送りを <fieldset disabled> で無効★、案内「編集中は絞り込みとページ送りを使えません」と失敗件数（{n}件を保存できませんでした）を出す
   • ★キャンセルは下書きがあるときだけ window.confirm(t("変更を破棄しますか？"))★
4. 読み込み: t("読み込み中…") に直す（4-16）。effect の書き方は 4-18
5. ★key は item.id（文字列）のまま★

5-2. components/features/ds-alerts/DsAlertsScreen.module.css

編集ボタン・プルダウン・textarea・目印・案内・失敗の文言のクラスを ErrorsScreen.module.css から写す（★JP/EN で位置が動かないよう固定幅★）。

5-3. lib/i18n.ts

• 足すキー（★EN は暫定★）: "未解消・対応中": "Unresolved / In progress"（★副題は変えないので副題のキーは足さない★。U6）
• ★既にあるキーは足さない★: 未解消・対応中・解消・編集・保存・保存（{n}件）・キャンセル・保存中…・変更を破棄しますか？・編集中は絞り込みとページ送りを使えません・{n}件を保存できませんでした・備考を入力・読み込み中…
• ★未対応: "Unsupported"（:182）は変えない★（対応機種バッジの訳。U5 で D-Sec 画面がこのキーを使わなくなるだけ）
• 使わなくなるキー（「対応済み」「未対応・対応中」等）は ★他の画面で使っていないか grep してから★ 消す。★「全種別」「セキュリティ無効」「通信断」「セキュリティ無効・通信断のアラート管理」は使い続ける（U6）ので消さない★

5-4. 確認

画面のテストは vitest で走らない（vitest.config.ts）ので段階10 で見る。保存の規則は純粋関数（表3）と edit-drafts.test.ts で固定してある。

コミット。

段階6 — ローカルDB のシード（scripts/seed-local-db.ts）

★ローカル（dwatch_local）の /ds-alerts を空にしないため★。★lib/db/local-guard.ts は触らない★。

1. ★control_error_histories への投入をやめる★: import（:65 の dsAlerts、:44 の controlErrorStatusFromResolutionStatus）と、:812-830（security_off を弾く・件数7の検査）・:1160-1182（controlErrorHistory.create）を消す。 ★:900 の controlErrorHistory.deleteMany({}) は残す★（前回のシードの行を消すため）。:2238 の件数のログから control_error_histories を外す
2. ★robot_error_reports に D-Sec の行を入れる★: errorReportRows（lib/fixtures/error-reports.ts）のうち ★isDsAlertRow() と isVisibleErrorRow() の両方を通る行★（★FX-ERR-19 は入れない★ — ローカルでは施設の生きている清掃エリアに付け替わって出てしまうため）を、次の値で robotErrorReport.create:
   • id = error_id = fixtures の error_id／facility_id = fixtures の値／section_id = ★facilityIdToSectionId.get(facility_id)★（無ければ例外。:1094 と同じ）
   • robot_id = ★section_id と同じ値★（★ローカルのスキーマは robot_id が NOT NULL★。シードの既存の採番規則「sections.id とロボットの id は同値」に合わせたダミー。コメントで理由を書く）
   • clean_timetable_id = ★null★（fixtures の予定 id 9001 等はローカルに無い。予定不明として出さないため）
   • serial_number / error_type / error_level / status / comment / errored_at / created_at / responded_at / resolved_at は fixtures の値そのまま（日時は ★既に toDbJst() 済み★。もう一度通さない）
   • error_detail = 既存の ERROR_DETAIL_PLACEHOLDER
3. 件数の検査: ★D-Sec の行が7件★でなければ例外で止める（既存の「想定と異なれば中断」の作法）
4. ★清掃エリア名は fixtures の section.section_name ではなく、ローカルの sections の名前で出る★（USE_FIXTURES の true/false で清掃エリア名だけ違う。承知のうえ。コメントで書く）

コミット（シードだけで1つ）。

段階7 — （別件・独立）清掃詳細ログの 11px 横スクロールを消す

★段階1〜6 と独立★。先にやってもよい。★コミットは別にする★。

7-1. 原因（監督の調査）

画面幅 1440px のとき、表の入れ物の幅 ＝ 1440 − サイドバー 220 − .main の左右 padding 64 − カードの枠 2 ＝ ★1154px★。 行が多くて .main に縦スクロールバー（15px）が出ると ★1139px★。表の最小幅は ★126 + 1024 ＝ 1150px★ なので、★11px 横スクロールする★。

7-2. 直し方 — components/features/detail-log/CleanLogTable.module.css

• :38 の ★--col-facility: 126px; → 110px;★ → 最小幅 ★110 + 1024 ＝ 1134px★。 縦スクロールバーが 17px でも入れ物は 1137px なので収まる。★画面幅 1435px 以上で横スクロールが出ない★（スクロールバー 15px のとき）
• ★他の列は変えない★（.compact の 240px も変えない）
• 見出し「施設名」/ EN「FACILITY」（11px・太字・大文字・字間 0.6px）≒ 65px ＋ padding 24px ＝ 約 89px なので 110px に収まる。中身は overflow-wrap: anywhere で折り返す（★長い施設名は1行増えることがある。承知のうえ★）

7-3. 古いコメントを直す

★D-178 の決定文（docs/decisions.md:12901 以降）にある「最小幅 1150 を変えないため」は本書では直さない★（docs/decisions.md は D-180 の追記だけ。§13 の下書きに「D-178 の 1150 は 1134 に読み替える」と書いてある）。

7-4. 範囲外（触らない・報告だけ）

施設ロボットマスタ（FacilitiesScreen）の表は min-width: 1300px で、画面幅 1440px では約 161px はみ出す（既知。コメント :43 のとおり）。★本書では直さない★。

段階8 — 資料（本書で直すのは次だけ）

1. docs/fixtures.md:
   • §1（:21）の ds-alerts.ts を消す
   • §6（:293-305）を書き換える: ★D-Sec アラートは errorReportRows の D-S_CONTROL_FAILURE 行から作る（7行。§13 の FX-ERR-10・12〜17）★／状態3つ・備考あり／なし・errored_at NULL・シリアルと施設の食い違い・同時刻／★security_off は fixtures にも無い（D-180）★／★「disconnected × done で0件」の意図的な0件は無くなった★（0件を見たいときは分類で絞る）
   • §12（:444-451）: security_banner の「複数件」の行に「★fixtures・DB とも security_off が無いので出ない（D-180）。描画は aggregate.test.ts で検証★」、:451 の section_name の注記を消す
   • §13（:503-）: ★19行（見える行17）★・既定14・全17、FX-ERR-12〜19 の行（★FX-ERR-18・19 は削除済みの施設・清掃エリアなので、エラー一覧にも D-Sec にも出ない。U8★）、FX-ERR-08・11 のシリアル ---、既定の並び（★表の時刻から手で導く★）
2. d-watch-api.yaml / lib/types/index.ts / ルートの冒頭コメント（段階2・4 で書いたもの）
3. ★docs/decisions.md に D-180 を追記★（§13 の下書き。★追記直前に grep -n "^### D-1[78][0-9]" docs/decisions.md で最終番号を確かめる★。D-179 の本文は触らない。★他のセッションの未コミットの差分を自分のコミットに含めない — git add -p で D-180 の塊だけを選ぶか、D-179 がコミットされるのを待つ★）

★CLAUDE.md / docs/code-map.md / docs/spec.md / docs/handoff.md は監督が直す★（§12 の監督向けの申し送り）。

段階9 — 全体の確認

1. npx tsc --noEmit -p . — 0件
2. npm run lint — 0件（★eslint-disable を足していない★・i18n の重複キー・$queryRaw・any・未使用の import が無い）
3. npm test — ★全件通過★（段階0 の件数から増えている）
4. ★USE_FIXTURES=true で npm run build★ — 成功（★ワークツリーではなく本体で★。Turbopack が node_modules のジャンクションを拒否する）
5. 最後の grep（★0件になること★。ただし $queryRaw は既存の「使わない」と書いたコメントだけ）:

   grep -rn "controlErrorHistory" app lib components --include=*.ts --include=*.tsx | grep -v generated | grep -v __tests__
   grep -rn "resolutionStatusFromControlErrorStatus\|controlErrorStatusFromResolutionStatus\|DsAlertStatus\b" app lib components scripts
   grep -rn "\"pending\"\|\"done\"" lib/ds-alerts components/features/ds-alerts lib/dashboard
   grep -rn "memo" lib/types/index.ts lib/ds-alerts components/features/ds-alerts lib/db/ds-alert-mapping.ts
   grep -rn "robot_id: true\|robot: true\|robot: {" lib/db/robot-error-select.ts
   grep -rn "ds-alerts/{id}/status" d-watch-api.yaml
   grep -rn "\$queryRaw\|\$executeRaw" app lib components

段階10 — 画面での確認

★アプリ内ブラウザ（mcp__Claude_Browser__*）を使う。Edge（ヘッドレス・CDP を含む）は使わない★（ユーザー指示 2026-10-16）。 ★ユーザーの :3000（next dev。ステージング向け）は止めない★。

10-1. fixtures（:3100）

1. 本体で USE_FIXTURES=true npm run build（PowerShell: $env:USE_FIXTURES='true'; npm run build）
2. ★テスト用の AUTH_TOKEN をその場で生成★（例: Node の crypto.randomBytes(24).toString("hex")）し、★環境変数で渡して★ USE_FIXTURES=true npx next start -p 3100 で起動（process.env は .env.local より優先）。★トークンを文書・コミット・報告に書かない★
3. preview_start の url で http://localhost:3100 を開き、ログイン画面にそのトークンを入れる
4. 確かめること（read_page / get_page_text / javascript_tool / スクリーンショット）:
   • ★D-Sec アラート★: 既定で ★5件★、数値カード ★未解消3・対応中2・解消2★（表4 の文言）。FX-ERR-16 が施設3の名前で出る。FX-ERR-12 の検知時刻が created_at（当日 02:55）。★「セキュリティ無効」のカードが無い★。★種別のセレクトは残っていて、「セキュリティ無効」を選ぶと0件・「通信断」で5件★（U6・表2 A5）
   • 状態ボタン「全件」で7件、「解消」で2件
   • ★削除済み（U8）★: /errors（「解消済みも表示」オンでも）と /ds-alerts（「全件」でも）に ★FX-ERR-18・19 が出ない★。javascript_tool で fetch("/api/errors/FX-ERR-18/status", { method: "PATCH", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ status: "in_progress" }) }) → ★404★（fixtures の上書き表だけなので実害なし）
   • ★編集モード★: 編集 → FX-ERR-10 を「解消」・FX-ERR-12 に備考 → 保存（2件） → 通常モードに戻り、★FX-ERR-10 は「未解消・対応中」の表示のまま残る★（取り直すまで）・数値カードが ★未解消2・対応中2・解消3★ に変わる（保存前は 3・2・2。FX-ERR-12 は備考だけなので数は変わらない）
   • ★同じ行がエラー一覧にも反映★: /errors で FX-ERR-10 が「解消」・FX-ERR-12 の備考が出る。★逆に /errors で FX-ERR-13 を「未解消」にすると /ds-alerts に反映★
   • 編集中: 絞り込み・ページ送りが無効、下書きがある状態でリロードすると確認が出る（beforeunload）、キャンセルで確認 → 下書きが消える
   • ★JP/EN 切替★で、ボタン・プルダウンの位置が動かない。EN で「未対応」が "Unsupported" と出ない
   • ★清掃詳細ログ（段階7）★: resize_window で 1440×900 にし、★行が多くて縦スクロールが出ている状態★（期間を広げる・per_page を最大に）で、JP と EN の両方で:

     const w = document.querySelector('[class*="tableWrap"]');
     const main = document.querySelector('main') ?? document.querySelector('[class*="main"]');
     ({ scroll: w.scrollWidth, client: w.clientWidth, scrollbar: main.offsetWidth - main.clientWidth })

     ★scroll === client★ であること。★scrollbar が 0 なら縦スクロールバーが出ていない（オーバーレイ型）ので、そのことを報告する★（それでも scroll === client を確かめる）。終わったら resize_window を desktop に戻す
5. ★終わったら :3100 の listen プロセスを止める★（自分で起動したものだけ）

10-2. ローカルDB（dwatch_local。条件付き）

npm run seed:local（★ローカル以外を拒否する★）→ USE_FIXTURES=false で ★ホストが localhost・DB 名が dwatch_local であることを検査してから★ next start -p 3100:

• /ds-alerts に7件（既定5件）。1行を「対応中 → 解消 → 未解消」・備考を入れて空に → サーバーのログに db.write が success: true・route が /api/errors/[error_id]/status・備考の中身なし。最後は元の値に戻す

段階11 — ステージングで確かめる（★条件付き。満たさなければ止まって報告★）

着手の条件（すべて）: ステージングに接続できる（★別の認証情報を探したり試したりしない★）／D-S_CONTROL_FAILURE の行が3行ある（2026-10-19 時点。★件数が違えば、書かずに件数だけ報告★）。

手順（★ステージングへの4カラムの書き込みはユーザーが許可済み。D-152 / CLAUDE.md §3★）:

1. ★削除済みの施設・清掃エリアに紐づく行を数える（読むだけ）★: robot_error_reports を facilities / sections と結合し、どちらかの deleted_at が NULL でない行の件数と error_type を記録する。★0件でなければ、下の「3行」等の期待値はその分減る★（減った数と一致すれば合格。食い違えば書かずに報告）
2. ユーザーの :3000 経由（止めない）。★/ds-alerts が3行（既定で未解消の2行、「全件」で3行・解消1行）★、★1000004 が施設3で出る★、検知時刻が created_at（16行すべて errored_at NULL）、★SECURITY_ON・NOT_STARTED が出ない★
3. ★書き込むのは1行だけ★。未解消・responded_at / resolved_at / comment が空の D-Sec の行を選ぶ
4. ★操作前の値を記録する★: error_id と4列。★mysql で SELECT するだけ★（UPDATE / DELETE / INSERT を手で打たない。パスワードは表示しない）
5. ★D-Sec 画面の編集モードで★: 対応中 → 保存 → 解消 → 保存 → 未解消 → 保存、備考を入れて保存 → 空にして保存。★途中でエラー一覧（/errors）にも同じ状態が出ること★を見る
6. ★最後に4列が操作前と完全に一致すること★（updated_at は DB が更新するので戻らない — 値を記録して報告。AT §10 #8 で受け入れ済み）
7. ★途中でデータが入れ替わったら止めて報告★（第10回 N-6）。★他の行に書いて代わりにしない★
8. ★npm run seed:local をステージングに向けない★

8. テスト一覧（本書で足す・直すもの）

9. 触ってよいもの・触ってはいけないもの

触ってよい

lib/config/index.ts（定数1つ）・lib/types/index.ts（DsAlert まわり）・lib/db/robot-error-select.ts（定数1つと、既存2定数への deleted_at の追加）・lib/db/ds-alert-mapping.ts（新規）・lib/db/index.ts（dsAlerts() 2本と import、★U8 の errorReportById() 2本・errorReportItemsInPageOrder()★）・ ★lib/db/error-report-mapping.ts（2-7 の可視性の型・isVisibleErrorRow()・ERROR_ROW_VISIBLE_WHERE・errorReportListWhere() だけ）★・★lib/error-reports/query.ts（filterSortErrorReportKeys() の visible の1行だけ）★・ lib/db/ds-status.ts（2関数の削除）・lib/ds-alerts/query.ts・lib/ds-alerts/edit.ts（新規）・lib/dashboard/aggregate.ts（★!== "done" → !== "resolved" の1か所とコメントだけ★）・ lib/fixtures/error-reports.ts・lib/fixtures/ds-alerts.ts（削除）・lib/fixtures/index.ts（1行）・app/api/ds-alerts/route.ts・app/api/dashboard/route.ts（コメントだけ）・ components/features/ds-alerts/DsAlertsScreen.tsx・.module.css・lib/i18n.ts・scripts/seed-local-db.ts（段階6 の範囲だけ）・ components/features/detail-log/CleanLogTable.module.css（段階7）・FacilitiesScreen.module.css / CleanAreaScreen.module.css / DsLogScreen.module.css（★コメントだけ★）・ d-watch-api.yaml・docs/fixtures.md・docs/decisions.md（★D-180 の追記だけ★）・§8 のテスト

触ってはいけない

• ★CLAUDE.md★（監督が直す。いま別のセッションが編集中）・★docs/decisions.md の D-179 とそれ以前の本文★・docs/code-map.md・docs/spec.md・docs/handoff.md
• ★docs/handoff/TeamWorks確認事項_第13回_*・docs/handoff/回答待ち一覧_*・docs/handoff/pdf/*★（他のセッションの作業）
• d-watch-mock.jsx（モックは書き換えない。U5 の文言の食い違いは承知のうえ。ユーザー確定）
• ★prisma/schema.prisma / lib/generated/prisma/**★（db pull しない。D-172。RobotErrorReport.updated_at に @updatedAt を付けない）
• ★lib/db/robot-error-write.ts・app/api/errors/** のルート・lib/prechecks/status-update.ts・lib/prechecks/edit-drafts.ts の中身★（書き込みの規則は1本。D6）
• lib/db/precheck-mapping.ts の中身（resolutionStatusFromRobotErrorStatus() 等は使うだけ）・lib/db/error-report-mapping.ts の ★2-7 以外★（errorScheduleLink() / errorReportItemFromRow() の規則）
• ★施設名・分類の解決（lib/facilities/resolve-by-name.ts / resolve-by-master.ts / lib/db/facility-name-source.ts / facility-group-source.ts）★（deleted_at で絞らない＝罠7 を変えない）
• ★/alerts の読み取り（prechecks() / precheckItemById()）★（U8 は範囲外。§12-2）
• components/features/errors/**・components/features/alerts/**（写すだけ。変えない）
• dsDevices() / /ds-logs / lib/fixtures/ds-devices.ts（D-Sec ログは影響なし）
• computeSecurityBanner() の中身（"done" → "resolved" の1か所以外）・components/features/dashboard/**
• lib/db/local-guard.ts
• ★4カラム以外への書き込み・生SQL・eslint-disable の追加★
• ★認証情報（パスワード・接続文字列・DB のユーザー名・生成したトークン）を文書・コード・テスト・コミット・作業報告に書くこと★
• ★git add -A★

10. 範囲外（本書ではやらない）

• ★ダッシュボードのセキュリティバナーを廃止する／別の意味（例: 未解消の D-S_CONTROL_FAILURE）に転用する★（コードを残すことはユーザー確定。U7・§11 Q3）
• ★facilities.contract による D-Sec メニュー・データの出し分け★（CLAUDE.md §4.6。P2）
• エラーの区分（ロボット／制御盤／セキュリティ／清掃開始失敗）を画面に作ること（D-160 のまま生値）
• prisma db pull（robot_id NULL 可・serial_number の拡張の取り込み。D-172）
• 関数名・型名の一般化（PrecheckStatus → ResolutionStatus 等。指示書AW §10 と同じ）
• 施設ロボットマスタの表の横スクロール（段階7-4）
• D-Sec 画面のサーバー側ページ分け・SQL への絞り込みの降ろし込み（行数が少ないので今のまま）
• ★/alerts（事前チェック＋出発失敗）で削除済みの施設・清掃エリアの行を外すこと★（U8 はエラー一覧と D-Sec だけ。§12-2 で監督が確かめる）
• 施設名・分類の解決、清掃詳細ログ・レポート・清掃面積など、他の画面の deleted_at の規則（罠7 を含む）

11. 質問と回答（2026-10-19）

★Q1〜Q3・Q5〜Q8 は確定し、本文に反映済み。未確定は Q4 だけ★。

11-1. ユーザーへの質問（監督経由）

11-2. 監督への質問 → ★すべて本書のとおりで確定（監督判断 2026-10-19）★

11-3. 監督への質問（★U8 で増えたもの。段階1 の前に要る★）

12. 申し送り

12-1. TeamWorks へ（★監督が確認事項にまとめる。本書の実装では送らない・docs/handoff/TeamWorks確認事項_第13回_* は触らない★）

1. ★error_id 1000004（D-S_CONTROL_FAILURE）★: シリアル DFAS010001 は施設2の制御盤だが、行の facility_id / section_id は 3（2026-10-19 監督の SELECT・先方投入）。 当方は P-8 d = A のとおり ★行の施設（3）で出す★。★どちらが正しいか（行の施設の誤りか、制御盤の付け替えか）★を確かめたい。
2. ★セキュリティ（SECURITY_ON）・清掃開始失敗（NOT_STARTED）の serial_number★: 第11回 P-8 の回答は 0 だが、ステージングの実値は ★---★（6行すべて）。当方は値で見分けないので影響は無いが、★今後どちらに揃うのか★を確かめたい（第10回 N-5 では「serial_number が null」という案もあった）。
3. ★errored_at がすべて NULL★（16行。2026-10-19）。当方は created_at で代用している。★errored_at は今後入るのか★（入らないなら「エラーが起きた時刻」ではなく「記録した時刻」が画面に出ている）。

12-2. 監督へ（CLAUDE.md 等、本書の実装では直さないもの）

1. CLAUDE.md §4.7 の取得元の表の「エラー」の行 — 「★3区分の見分けと D-Sec アラートの取得元の切り替えは次フェーズ★」を、本書の実装後に「D-Sec アラートは robot_error_reports の D-S_CONTROL_FAILURE（D-180）」に。§3 の接続先の注記の P-8 のシリアル '0' も実値 --- の注記を
2. docs/decisions.md の D-091 項3 の「確認が必要なこと（バナーをどうするか）」は、★コードを残す★ことでユーザー確定（§11 Q3）。廃止・転用するかは未決のまま
3. docs/code-map.md / docs/spec.md（/ds-alerts の取得元・編集モード）
4. 指示書AW の表1 E8（シリアル '0'）は単体テストの行なので変えていない。fixtures と資料だけ --- にした
5. ★/alerts（事前チェック＋出発失敗。prechecks() / precheckItemById() / PATCH /prechecks/{id}/status）は、削除済みの施設・清掃エリアの行を出しているか確かめてほしい★（本書の範囲外。U8 の「エラー一覧からもD-sec一覧からも」に /alerts は入っていない）。出しているなら、同じ規則（isVisibleErrorRow()）に揃えるかをユーザーに確かめる
6. CLAUDE.md に U8（削除済みの施設・清掃エリアの行はエラー一覧・D-Sec に出さない。罠7 の解決は別）を足すかどうか

13. 決定の記録（★D-180 の下書き★。実装時に docs/decisions.md の末尾に追記する）

### D-180 `[決定]` D-Sec アラートを `robot_error_reports`（`D-S_CONTROL_FAILURE`）から読み、D-Sec 画面に編集モードを付ける

★根拠★: TeamWorks 第11回 P-10 = A（`robot_error_reports` を正とする。D-Sec のアラートも対応状況の更新もこちら。`control_error_histories` は読まない）／
P-8（制御盤のエラーは `robot_id` NULL・シリアルは制御盤の SN。施設は行の `facility_id`・`section_id`）／第10回 N-5（`error_type` の値）／
ユーザー判断 2026-10-19（下の1〜4・7・7b・11）。指示書AX。

1. ★`SECURITY_ON` は D-Sec アラートに出さない★（エラー一覧には出る）。D-091 項3「セキュリティが無効であっても異常ではない」と一致
2. ★`NOT_STARTED`（清掃開始失敗）も D-Sec アラートに出さない★（ロボット側の出発失敗）
3. ★施設は行の `facility_id`★（P-8 d = A）。ステージングの 1000004 はシリアルが施設2の制御盤なのに行は施設3 → ★施設3で出す★（TeamWorks に申し送り）
4. ★D-Sec アラート画面に編集モードを付ける★（エラー一覧と同じ操作。D-161 / D-165）。書くのは同じ行の4カラム。★書き込みは `PATCH /errors/{error_id}/status` の1本★（新しいルートを作らない。YAML の未実装の `PATCH /ds-alerts/{id}/status` は削除）
5. ★対象は `error_type` が `D_SEC_ALERT_ERROR_TYPES`（`lib/config/index.ts`。初期値 `["D-S_CONTROL_FAILURE"]`）に完全一致する行★。★SQL の `IN` は写し、正は JS の `===`★（照合順序が大小文字・末尾の空白を区別しないため）。★`robot_id IS NULL` やシリアルの形では見分けない★（実データのシリアルは回答の `0` ではなく `---`）。`status` は 0/1/2 の行だけ（3以上は出さず例外にもしない — ダッシュボードを落とさない）
6. ★`DsAlert` の契約★: `id` は string（`error_id`）／`resolution_status` はエラー一覧と同じ `unresolved` / `in_progress` / `resolved`（`DsAlertStatus` は削除。変換は `resolutionStatusFromRobotErrorStatus()` の1本）／`memo` → `note`／`status` パラメータは `open` / `all` / `resolved`（旧 `done` は422）／`summary` のキーも同じ／`detected_at` は `errored_at ?? created_at`／`section_name` は行の `section_id` の清掃エリア名（暫定のダミーではなくなった）
7. ★`alert_type` の `security_off` は互換のため enum に残すが、DB からは出ない★。★ダッシュボードのセキュリティバナーは DB のデータでは常に空★（★コードとテストは残す — ユーザー確定 2026-10-19★。廃止・転用は未決 — D-091 項3 の「確認が必要なこと」）
7b. ★D-Sec 画面の対応状況の文言はエラー一覧に揃える（未解消 / 対応中 / 解消）★（ユーザー確定 2026-10-19。モックの「未対応 / 対応済み」とは食い違う）。★種別のセレクト（全種別 / セキュリティ無効 / 通信断）と副題はそのまま残す★（ユーザー判断 2026-10-19。「セキュリティ無効」を選ぶと0件になることは承知のうえ）
8. `control_error_histories` はアプリから読まない（シードも書かない。`deleteMany` だけ残す）。`lib/db/ds-status.ts` の制御盤エラーの変換2関数は削除
9. fixtures: D-Sec アラートは `errorReportRows` の `D-S_CONTROL_FAILURE` 行（7行）から同じ純粋関数で作る（`lib/fixtures/ds-alerts.ts` は削除）。セキュリティ・清掃開始失敗のシリアルを実データどおり `---` に
10. （別件）清掃詳細ログの施設名の列を 126px → 110px（表の最小幅 1150 → 1134px）。画面幅 1440px で縦スクロールバーが出ると入れ物が 1139px になり、11px 横スクロールしていた。★D-178 の「最小幅 1150 を変えないため」は 1134 に読み替える★
11. ★削除済み（論理削除）の施設・清掃エリアの行は、エラー一覧（`GET /errors`・`meta.total`）からも D-Sec アラート（`GET /ds-alerts`・`summary`・ダッシュボード）からも外す。その行への `PATCH /errors/{error_id}/status` は404★（ユーザー決定 2026-10-19「削除済みのものは表示する必要がないので、エラー一覧からもD-sec一覧からも消してください」）。★`deleted_at` が NULL でなければ削除済み★。正は `isVisibleErrorRow()`、SQL の `ERROR_ROW_VISIBLE_WHERE` は写し。★施設名・分類の解決は従来どおり `deleted_at` で絞らない（罠7）★。★`/alerts` は範囲外（出しているかは要確認）★

★`memo` → `note`・`done` → `resolved`（旧 `done` は422）・期待値表（指示書AX §3）・シードの手当ては監督判断 2026-10-19★。
★ユーザー回答待ちの暫定は無い★（指示書AX §11 Q1〜Q4 はすべて確定）。

（★実装の記録（コミット・確認の結果）は、実装後に D-180 の末尾に「実装の記録」として足す★）

14. コミット

段階ごとに分ける（段階1 / 段階2 / 段階3 / 段階4 / 段階5 / 段階6 / ★段階7（別件）★ / 段階8）。★git add はファイルパスを明示する★（git add -A 禁止）。 メッセージには ★何を変えたか★ と ★なぜ（P-10 = A。D-Sec アラートを robot_error_reports から読む。D-180）★ を書く。★段階1 は「テストだけ（この時点では落ちる）」と明記★。 ★docs/decisions.md は D-180 の塊だけをコミットする（D-179 の未コミットの差分を巻き込まない）★。 ★PR の作成とマージは daichi がレビューしてから★（D-154）。

15. 完了条件

• §11 の確定（Q1〜Q8）どおりに実装した。★Q9（表5）の監督の確認を取ってから段階1 に入った★
• ★削除済みの施設・清掃エリアの行（表5 V2・V3・V5〜V7）が、エラー一覧（meta.total を含む）にも D-Sec アラート（summary を含む）にも出ない。PATCH は404で updateMany を呼ばない★（fixtures の FX-ERR-18・19 で画面と API の両方を確かめた）
• 施設名・分類の解決（罠7）と /alerts の読み取りは変えていない
• D-Sec 画面の種別セレクトと副題が今のまま残っている（U6）
• tsc 0件・lint 0件・npm test 全件通過（件数が増えている）・USE_FIXTURES=true npm run build 成功
• 段階9 の grep がすべて0件（$queryRaw は既存のコメントだけ）
• アプリが control_error_histories を読まない。robot_error_reports の読み取りは定数の select だけ（robot_id / robot を含まない）
• 書き込み経路は PATCH /errors/{error_id}/status の1本（新しいルート・DataSource の書き込みメソッドが無い）。YAML に /ds-alerts/{id}/status が無い
• fixtures（:3100）で段階10-1 の項目をすべて確かめた（D-Sec 5件・編集モードの保存・エラー一覧との相互反映・JP/EN）
• 清掃詳細ログ: 1440px・縦スクロールあり・JP/EN で tableWrap.scrollWidth === clientWidth
• （条件が揃えば）ステージングで3行が出て、1行の往復の後に4列が操作前と完全に一致した
• docs/fixtures.md・YAML・型のコメントを直し、docs/decisions.md に D-180 を追記した（D-179・CLAUDE.md には触っていない）
• 作業報告に: コミット一覧／テスト件数（前後）／画面確認の結果（出所: 当方の fixtures 由来・当方のシード由来・先方投入 を書き分ける。CLAUDE.md §6-6）／本書と違う判断をしたところ