/**
 * レポート系メソッド（reportKpis / facilityPerformance / errorBreakdown / continuousProblems）を
 * 組み立てるときの変換ロジック（純粋関数のみ）。
 *
 * ★`lib/db/clean-log-mapping.ts` と同じ作法★ — DBアクセスを混ぜず、`prismaSource` の
 * 各メソッドから呼ぶだけにして、テストは fixtures 相当の入力と純粋関数だけで書けるようにする
 * （指示書T 2-4 / CLAUDE.md 禁止事項13）。
 *
 * ★`continuousProblems` は指示書Wで実装した（第6歩当時は対応するサマリテーブルが無く先送り
 *   していたが、詳細テーブルから算出する形で実現した。D-102項4）★。
 */
// ★完了率は1回ごとの完了率（`runCompletionRate()`）の単純平均（`meanCleanRatio()`）★（D-155）。
//   ★`meanCleanRatio()` は `lib/judge/kpi.ts` に移した★（2026-09-30。`CLAUDE.md` §9.1:
//   KPI計算は `lib/judge/`。★レポート画面・F-08・エリア別完了率・R-3 が同じ関数で畳む★。§5-1）。
//   ★面積比の `completionRate()` は使う箇所が0件になったので削除された★。
import {
  errorRate,
  isCompletedTask,
  judgeEscalationLevel,
  launchRate,
  meanCleanRatio,
  operationRate,
  runCompletionRate,
  toKpiValue,
} from "@/lib/judge";
import { capConsecutiveDays } from "@/lib/format/consecutive-days";
import { fromDbJst, jstIsoFromDb } from "@/lib/format/date";
import { isResultPending } from "@/lib/clean-logs/result-pending";
import { weekOfMonth } from "@/lib/format/period";
import type {
  ContinuousProblem,
  ErrorBreakdownItem,
  Period,
  ReportKpi,
  ReportPeriodKey,
} from "@/lib/types";
// ★`notExecutedFromHistory()` / `CleanResultLike` はもうこのファイルからは使わない★ —
//   `clean_task_reports` には `clean_error` 相当の列が無く（指示書AQ 1-1）、
//   ★未実施の判定は `aggregateCleanStatsByFacility()` の引数（述語）で受け取る★形にしたため。
//   ★新しい判定関数を作るのは担当C★（`lib/db/clean-log-mapping.ts`）。
import {
  foldProblemDaysByDate,
  isFutureSchedule,
  type ConsecutiveInput,
} from "./clean-log-mapping";
// ★`detectedAtFromError()` はもうこのファイルからは使わない★（期間帰属を本清掃の `start_at` に
//   変えたため。決定7）。★関数自体は削除しない — `prechecks()`（アラート）が使っている★
import type { PrecheckDetectedAtSource } from "./precheck-mapping";

// ---------------------------------------------------------------- 連続問題施設（summary テンプレート）

/**
 * `ContinuousProblem.summary` に返す3種のテンプレート文字列（指示書W 確定1・確定2・確定3）。
 *
 * ★数値を埋めずにテンプレートのまま返す（方式A）★ — 画面側が `{n}` に
 *   `consecutive_problem_days`、`{m}` に `launch_failed_days` を差し込む。
 * ★★`lib/i18n.ts` に足すキーと1文字も違ってはいけない★★（全角括弧・「うち」・「は」を含む）。
 *   違うと `translate()` が未登録キーとして日本語のまま返す（fail-silent。D-111 項8）。
 * ★対処の助言も原因の推定も含まない（確定1。D-111）★。
 */
export const SUMMARY_TEMPLATE_COMPLETION = "{n}日連続で完了率が△以下";
export const SUMMARY_TEMPLATE_LAUNCH_FAILED = "{n}日連続で出発失敗";
export const SUMMARY_TEMPLATE_MIXED = "{n}日連続で△以下（うち{m}日は出発失敗）";

/**
 * 連続日数が★表示上限で頭打ちになった★ときのテンプレート3種（指示書AF 段階5-1）。
 *
 * ★数値を埋めずにテンプレートのまま返す（方式A）★ — 上の3本と同じ。
 * ★★`lib/i18n.ts` に足すキーと1文字も違ってはいけない★★（全角括弧を含む）。
 *   違うと `translate()` が未登録キーとして日本語のまま返す（fail-silent。D-111 項8）。
 * ★対処の助言も原因の推定も含まない（確定1。D-111）★。
 */
export const SUMMARY_TEMPLATE_CAPPED_COMPLETION = "{n}日以上連続で完了率が△以下";
export const SUMMARY_TEMPLATE_CAPPED_LAUNCH_FAILED = "{n}日以上連続で出発失敗";
/** ★★`{m}` を持たない★★ — 上限で切った窓の中の内訳は計算できないため（指示書AF §B-5） */
export const SUMMARY_TEMPLATE_CAPPED_MIXED = "{n}日以上連続で△以下（出発失敗を含む）";

// ---------------------------------------------------------------- 期間キー

/**
 * サマリ4テーブルの行（`month` / `week`）から `Period` を決める。
 *
 * | 条件 | 戻り |
 * |---|---|
 * | ★`month === 0 && week === 0`★ | ★`"yearly"`★ |
 * | `week === 0`（`month >= 1`） | `"monthly"` |
 * | それ以外 | `"weekly"` |
 *
 * ★★`month` を必ず見ること★★（`CLAUDE.md` §4.7 / 指示書AQ §3 罠2）—
 *   ★以前は `week === 0 ? "monthly" : "weekly"` で `month` を見ていなかった★ため、
 *   ★年次行（`month=0 && week=0`）が「月次」として静かに混入★した。
 *   呼び出し側の「年次除外 filter」が外れた瞬間、`customerSummariesByPeriodKey()` が
 *   ★`monthly/2026/0/0` の重複を検知して 500★ になる（＝気づけるのはそこまで行った時だけで、
 *   `errorBreakdownRowsFromSummary()` 側は★年次の件数を月次に足し込んだまま黙って通る★）。
 *
 * ★★引数は「行そのもの」を受ける（`(month, week)` の2引数にしない）★★ —
 *   `month` と `week` はどちらも `number` なので、★位置を取り違えても型エラーにならない★。
 *   サマリ行はいずれも `month` / `week` を持つので、呼び出し側は `row` をそのまま渡せる。
 *
 * ★`"yearly"` は `Period`（`lib/types/index.ts`）への追加が前提★ — 追加は★担当B★の担当。
 */
export function periodOfSummaryRow(row: { month: number; week: number }): Period {
  if (row.month === 0 && row.week === 0) return "yearly";
  if (row.week === 0) return "monthly";
  return "weekly";
}

/** `${period}/${year}/${month}/${week}` の形の Map キー（`reportKpis()` の前期引き用） */
export function periodMapKey(
  period: Period,
  year: number,
  month: number,
  week: number
): string {
  return `${period}/${year}/${month}/${week}`;
}

/**
 * `customer_summaries` 1行ぶんの最小限の形（`customerSummariesByPeriodKey()` の入力）。
 *
 * ★`customer_id` を `bigint | number` の両方で受ける★ — Prisma は `bigint` を返すが、
 *   スタブや検証スクリプトが `number` を渡しても ★`1n` と `1` が別の顧客として扱われない★
 *   ようにするため（判定は `String()` で正規化する。落とし穴: `1n !== 1`）。
 */
export interface CustomerSummaryOwnerLike {
  customer_id: bigint | number;
  year: number;
  month: number;
  week: number;
}

/**
 * `customer_summaries` の行を ★期間キー → 行★ の Map にする（`reportKpis()` の確定期間用）。
 *
 * ★★複数の顧客の行が混ざっていたら例外にする（D-5。ユーザー判断 2026-09-14）★★ —
 *   「★レポートのKPIは運用担当が判断に使う数字。別会社の数字で判断されるより、
 *   画面が出ないほうがまし★」。
 *
 * ★★検知を「期間キーの衝突」だけで書かないこと★★（★指示書AH 罠5★）—
 *   壊れ方は2系統あり、別々に選ばれる:
 *
 *   | | 何が起きるか |
 *   |---|---|
 *   | 前期比 | 期間キー（`customer_id` を含まない）の Map で★後勝ち上書き★ |
 *   | 当期の値 | `selectKpiRow()` の `rows.find()` が★最初の1行★を採る |
 *
 *   ★A社が当期の行だけ・B社が前期の行だけを持つとキーは衝突しない★が、
 *   ★前期比だけが静かに汚染される★（差分が両社の差という無意味な数字になる）。
 *   だから ★判定は「全行の `customer_id` が1種類か」★ で行い、キー衝突は別途併せて見る。
 *
 * ★★同一顧客で同じ期間キーが2行来た場合も例外にする★★（起草者の判断。ユーザー決定の拡張）—
 *   スキーマに一意制約が無いので起こりえて、★壊れ方（後勝ちで不定）が同じ★だから。
 *
 * ------------------------------------------------------------------------
 * ★★2026-09-16（指示書AK ★段階6★）— `where` を `customer_id` で絞るようになった★★
 * ------------------------------------------------------------------------
 * ★以前ここには「★`customer_id` で `where` を絞って回避しないこと★」と書いてあった★ —
 *   ★分類（ホールディングス／屋号）が画面から消えていた当時（D-053）は
 *   ★★どの顧客かを決める根拠が無かった★★ため。★その前提は変わった★:
 *   `/reports/kpi` は `group_id` / `customer_id` を実際に読み、
 *   ★`resolveTargetCustomer()`（`lib/reports/target-customer.ts`）が対象顧客を1社に決める★。
 *   ★決まらなければデータ層を呼ばずに 422★（指示書AK §2-1）。
 *   ★★だから「静かに1社を選ぶ」ことは今もしていない★★（D-133 の否定は生きている）。
 *
 * ★★それでもこの関数は残す★★（★指示書AK §9-2 の指定★）:
 *   - ★同じ期間キーの重複は同一顧客でも起こりうる★（`customer_summaries` に一意制約が無い。
 *     ★後勝ちで不定になる★。期待値表 6-8）
 *   - ★複数顧客の検知も防御的に残す★ — `where` の書き換えで絞りが外れたときに、
 *     ★静かに別会社の数字を混ぜるより止まるほうがまし★（D-5 のユーザー判断）
 * ★「期待する `customer_id`」を `lib/config/` に置くのは今も不可★（ユーザーが採らなかった案B）。
 *
 * ★★年次（`month === 0 && week === 0`）の扱い★★（★指示書AQ §3 罠2★）—
 *   ★`periodOfSummaryRow()` が `month` を見るようになった★ので、年次行が混ざっても
 *   期間キーは `yearly/2026/0/0` になり、★月次（`monthly/2026/9/0`）とは衝突しない★。
 *   ★以前ここには「年次を除外した**後**に呼ぶこと」と書いてあった★ — それは
 *   ★`periodOfSummaryRow()` が年次を「月次」と誤判定していた当時の回避策★であり、
 *   ★根本原因が直った今は前提条件ではない★（呼び出し側で年次を読むかどうかは
 *   `lib/db/index.ts` 側の判断。★担当G★）。
 *   ★ただし「同じ期間キーが2行」の検知はそのまま残る★ — 年次行が本当に2行あれば止まる。
 *
 * ★施設サマリ（`facility_summaries`）には広げない★（D-6）— あちらは Map キーに
 *   `facility_id` が入っているので★上書きが起きない★（壊れ方が違う）。
 *
 * ★例外メッセージには `customer_id` と期間キーだけを載せる★ — 施設名などの PII を入れない
 *   （ルート層は固定文言の500に潰すのでレスポンスには出ないが、ログには出るため）。
 */
export function customerSummariesByPeriodKey<T extends CustomerSummaryOwnerLike>(
  rows: readonly T[]
): Map<string, T> {
  // ★まず「全行の customer_id が1種類か」を見る（キー衝突より先。罠5）★
  const customerIds = new Set<string>();
  for (const row of rows) customerIds.add(String(row.customer_id));
  if (customerIds.size > 1) {
    throw new Error(
      `[report-mapping] customerSummariesByPeriodKey: customer_summaries に複数の顧客の行が混ざっています（customer_id=${[
        ...customerIds,
      ]
        .sort()
        .join(", ")}）。どの顧客のKPIかを決める根拠が無いため中断します（D-5 / D-053）`
    );
  }

  const byPeriodKey = new Map<string, T>();
  for (const row of rows) {
    const key = periodMapKey(periodOfSummaryRow(row), row.year, row.month, row.week);
    if (byPeriodKey.has(key)) {
      throw new Error(
        `[report-mapping] customerSummariesByPeriodKey: 同じ期間キー（${key}）の customer_summaries が複数あります（customer_id=${String(
          row.customer_id
        )}）。一意制約が無く後勝ちで不定になるため中断します（D-5）`
      );
    }
    byPeriodKey.set(key, row);
  }
  return byPeriodKey;
}

// ---------------------------------------------------------------- 確定期間（サマリテーブル由来）

/** サマリ行が持つ4本の率フィールド（customer_summaries / facility_summaries 共通） */
export interface SummaryRatios {
  operation_ratio: number;
  launch_ratio: number;
  clean_ratio: number;
  error_ratio: number;
}

/**
 * サマリ行の率 + 前期行の率 → `ReportKpi`。
 * ★サマリの値はそのまま `KpiValue.value` に入れてよい（D-094。率はすでに `double(4,1)`）★
 * ★履歴（詳細テーブル）から再計算しない（D-102 / CLAUDE.md 禁止事項1）★
 */
export function kpiFromSummaryRatios(
  current: SummaryRatios,
  prev: SummaryRatios | undefined
): ReportKpi {
  return {
    operation_rate: toKpiValue(current.operation_ratio, prev?.operation_ratio ?? null),
    launch_rate: toKpiValue(current.launch_ratio, prev?.launch_ratio ?? null),
    completion_rate: toKpiValue(current.clean_ratio, prev?.clean_ratio ?? null),
    error_rate: toKpiValue(current.error_ratio, prev?.error_ratio ?? null),
  };
}

// ---------------------------------------------------------------- 当期（詳細テーブルからその場集計）

/**
 * 当期のKPIを組み立てるための中間集計値（施設1件、または全社ぶんの合算）。
 *
 * ★★当期の3つの率はサマリと同じ式★★（第11回 P-6。D-158）。★どれも分母は `planned`★:
 *   稼働率 ＝ `completed` ÷ `planned` / 出発成功率 ＝ `executed` ÷ `planned` /
 *   エラー発生率 ＝ `errorCount` ÷ `planned`（上限で切らない）。完了率だけは `cleanRatioSum` ÷ `cleanRatioCount`。
 *
 * - `planned` ＝ 期間内・過去の本清掃の予定の数
 * - `executed` ＝ そのうちレポート行がある数（★開始できた回数＝出発成功率の分子★）
 * - ★`completed` ＝ そのうち最新のレポート行の `status` が正常終了の数（稼働率の分子。`isCompletedTask()`）★
 * - `errorCount` ＝ エラーの数（エラー発生率の分子）
 *
 * ★時刻の条件は無い★（P-6=A）。`clean_task_reports.started_at` は、予定のある清掃では予定の `start_at` と
 *   同じ値、予定外のタスクでは実際の開始時刻が入る（ユーザー回答 2026-10-05。`CLAUDE.md` §4.7）ので、
 *   ★定刻かどうかはそもそも区別できない★。★出発成功率は時刻を見ない（P-6=A）★。
 *   旧: 「`clean_timetables.started_at` は常に予定時刻と同値」と書き、稼働率と出発成功率に同じ `executed` を
 *   使っていた（その列は存在せず、記述が誤りだった。D-157）。
 *
 * ★不変条件: `completed ≤ executed ≤ planned`★（だから 稼働率 ≤ 出発成功率 ≤ 100）。
 * 確定期間（`kpiFromSummaryRatios`）はサマリの値をそのまま読む（D-158。ここは当期だけ）。
 */
export interface CleanStatsBucket {
  /** 清掃予定回数 */
  planned: number;
  /** 開始できた回数（レポート行がある回数）。出発成功率の分子 */
  executed: number;
  /** ★正常終了の回数（最新のレポート行の `status` が正常終了。`isCompletedTask()`）。稼働率の分子（P-6=A）★ */
  completed: number;
  /** 清掃対象面積の合計（㎡） */
  taskArea: number;
  /** 清掃面積の合計（㎡） */
  cleanArea: number;
  /**
   * エラー発生回数。
   *
   * ★★本清掃行（`precheck === CLEAN_TIMETABLE_PRECHECK.main`）を指す
   *   `robot_error_reports` の件数★★（TeamWorks 第8回 A7。2026-09-11。D-114 項2）—
   *   ★事前チェック行を指すエラーは含めない★（「事前チェックは本清掃を円滑に実施できる
   *   ためのものなので, サマリには含めない」という回答）。
   *   ★`clean_timetable_id` が `null` の行 / dangling の行も含めない★（決定3）。
   *
   * ★★以前ここには「事前チェック行に紐づく」と書いてあった★★ — ★第8回で質問する前の
   *   **仮定**であり、回答で逆だと分かった。★古い記述を残さない★（次に読む人が両方を信じるため）。
   *
   * ★分母は予定回数（第11回 P-6=B）★。
   *
   * ★清掃の結果は `clean_task_reports` だけから読み、`clean_error` 列は読まない★（D-151）。
   *   ★制御盤・セキュリティのエラー、清掃を開始できなかったエラーも `robot_error_reports` に入り★
   *   （第11回 P-8・P-10）、★`clean_timetable_id` も入る★（P-9=A）。
   *   ★本清掃の予定の id が入った行は、区分を問わずこの件数に入る★（どの予定の id が入るかは無回答）。
   *   ★区分（ロボット／制御盤／セキュリティ・清掃開始失敗）の見分けと D-Security アラートの取得元の
   *   切り替えは次フェーズ★（D-158 当方の対応5）。
   *   旧: 第8回 A6-1「`clean_error` 2/3 の清掃は行が作られない」— 第11回で変わった。
   */
  errorCount: number;
  /**
   * ★1回ごとの完了率（`runCompletionRate()` の戻り）の**合計**★（完了率の分子。D-155）。
   * ★名前は変えていない★（指示書AS D7）— 中身は `clean_task_reports.clean_ratio` 列ではない。
   *
   * ★★平均そのものを持たない理由★★ — ★率は加重平均できない★（`CLAUDE.md` §4.7 の
   *   「率は加重平均できないため合算できない」と同じ話）。★Σ と件数を別々に持てば、
   *   施設をまたいで合算しても平均が壊れない★（`sumCleanStatsBuckets()`）。
   *   平均を取り出すのは ★`meanCleanRatio()` だけ★。
   */
  cleanRatioSum: number;
  /**
   * 上の `cleanRatioSum` に足した件数（＝完了率の平均の★分母★）。
   * ★いまは `executed` と同じ値になる★（`task_area = 0` も 0% として数えるため。P-5=B。D-158）。
   * ★それでも別に持つ★（Σ と件数の組で `meanCleanRatio()` に渡す形を変えないため）。
   */
  cleanRatioCount: number;
}

export function emptyCleanStatsBucket(): CleanStatsBucket {
  return {
    planned: 0,
    executed: 0,
    completed: 0,
    taskArea: 0,
    cleanArea: 0,
    errorCount: 0,
    cleanRatioSum: 0,
    cleanRatioCount: 0,
  };
}

function addCleanStats(a: CleanStatsBucket, b: CleanStatsBucket): CleanStatsBucket {
  return {
    planned: a.planned + b.planned,
    executed: a.executed + b.executed,
    completed: a.completed + b.completed,
    taskArea: a.taskArea + b.taskArea,
    cleanArea: a.cleanArea + b.cleanArea,
    errorCount: a.errorCount + b.errorCount,
    cleanRatioSum: a.cleanRatioSum + b.cleanRatioSum,
    cleanRatioCount: a.cleanRatioCount + b.cleanRatioCount,
  };
}

/*
 * ★`meanCleanRatio()`（清掃完了率の畳み方）はここから `lib/judge/kpi.ts` に移した★（2026-09-30）—
 *   ★挙動は同じ★（単純平均・件数0は `null`）。根拠の docstring も一緒に移してある。
 *   ★`CleanStatsBucket` は `CleanRatioTally`（`cleanRatioSum` / `cleanRatioCount`）を満たすので、
 *   そのまま渡せる★。★ここで再定義しないこと★（畳み方が2箇所に分かれる）。
 */

/** 複数施設ぶんのバケットを1つに合算する（`reportKpis()` の全社集計用） */
export function sumCleanStatsBuckets(
  buckets: Iterable<CleanStatsBucket>
): CleanStatsBucket {
  let total = emptyCleanStatsBucket();
  for (const bucket of buckets) total = addCleanStats(total, bucket);
  return total;
}

/** `clean_timetables`（本清掃のみ）1件ぶんの最小限の形 */
export interface MainTimetableLike {
  id: bigint;
  facility_id: bigint;
  start_at: Date;
}

/**
 * ★当期の率の集計（`aggregateCleanStatsByFacility()`）が読む本清掃の形★ — `MainTimetableLike` ＋ ★`end_at`★。
 * `end_at` は ★結果待ち（`isResultPending()`）の判定用★（表2 C11。ユーザー判断 2026-10-07。D-173）。
 * ★`start_at` と同じ JST の壁時計値★（`fromDbJst()` を通す）。
 * ★`MainTimetableLike` に足さなかった理由★: エラー件数の集計（`errorCounts` 系）は終了時刻を使わないので、
 *   そちらの読み取りに列を増やさないため。
 */
export interface CleanStatsTimetableLike extends MainTimetableLike {
  end_at: Date;
}

/**
 * 本清掃行（`precheck === CLEAN_TIMETABLE_PRECHECK.main`）の id（文字列） → `start_at`。
 *
 * ★2つの用途を1本で賄う★ —
 *   1. ★キーの集合★が「本清掃行の id の Set」になる（エラーの分子の判定に使う）
 *   2. ★値★が期間帰属の基準になる（決定7。エラーの期間は本清掃の `start_at` の JST 日付）
 *
 * ★`BigInt` は `===` でキー比較できないので文字列化する★。
 */
export function mainTimetableStartAtById(
  mainRows: readonly MainTimetableLike[]
): Map<string, Date> {
  const map = new Map<string, Date>();
  for (const row of mainRows) {
    map.set(row.id.toString(), row.start_at);
  }
  return map;
}

/**
 * `robot_error_reports` を ★本清掃id単位★ の件数に集計する（★エラー率の分子★）。
 *
 * ★★分子の定義（TeamWorks 第8回 A7。2026-09-11。D-114 項2）★★:
 *   ★本清掃行を指すエラーだけを数える★。★事前チェック行を指すものは含めない★
 *   （「事前チェックは本清掃を円滑に実施できるためのものなので, サマリには含めない」）。
 *
 * ★★「本清掃行の集合に**入っている**」という肯定条件で数える★★ —
 *   `clean_timetable_id` には FK も KEY も無く（`prisma/schema.prisma`。
 *   `lib/db/index.ts` の落とし穴1）、★`null` も dangling もありうる★ので
 *   「事前チェックでない＝本清掃」と推測してはいけない。
 *   ★`null` と dangling はこの条件の自然な帰結として落ちる★（決定3。特別扱いのコードを足さない）。
 */
export function errorCountByMainTimetable(
  errorReports: readonly { clean_timetable_id: bigint | null }[],
  mainStartAtById: ReadonlyMap<string, Date>
): Map<string, number> {
  const result = new Map<string, number>();
  for (const report of errorReports) {
    if (report.clean_timetable_id === null) continue;
    const key = report.clean_timetable_id.toString();
    if (!mainStartAtById.has(key)) continue;
    result.set(key, (result.get(key) ?? 0) + 1);
  }
  return result;
}

/**
 * `clean_task_reports` 1行ぶんの、この集計に必要な最小限の形（指示書AQ 決定2）。
 *
 * ★`clean_error` は持たない★ — `clean_task_reports` に ★`clean_error` 相当の列が無い★
 *   （指示書AQ 1-1）。★未実施の判定はこの型からは出せない★ので、
 *   `aggregateCleanStatsByFacility()` は判定を★引数（`isNotExecuted`）で受け取る★。
 * ★`clean_area` / `task_area` は1回ごとの完了率（`runCompletionRate()`）の材料★（D-155）。
 *   面積の合計（`taskArea` / `cleanArea`）にも足す。
 * ★`clean_ratio` は完了率に使っていない★（D-155）。★`runCompletionRate()` を列に戻すときのために
 *   残している★（指示書AS D6）。
 *
 * ★★`lib/db/clean-log-mapping.ts` の `CleanTaskReportLike`（★担当C★）とは別の型★★ —
 *   いまは列が同じだが、★用途が違う★（あちらは清掃詳細ログ1行の完了率、こちらは期間集計）ので、
 *   ★名前を分けてある★
 *   （同名の型が2つあると、`lib/db/index.ts` が両方を import したときに
 *   ★どちらの意味か読めなくなる★）。★TypeScript は構造的部分型なので、
 *   面積列を含む行はそのまま両方の引数に渡せる★。
 */
export interface CleanStatsReportLike {
  clean_ratio: number;
  task_area: number;
  clean_area: number;
  /**
   * `clean_task_reports.status`。★稼働率の分子（`isCompletedTask()`）にだけ使う★（第11回 P-6=A）。
   * ◎○△× の判定・未実施の判定には使わない（D-155 項2）
   */
  status: number;
}

/**
 * 本清掃行 + 清掃結果（`clean_task_reports`）+ エラー件数（本清掃id単位）から、
 * 期間内・施設ごとの `CleanStatsBucket` を作る。
 *
 * ★未来の予定（`isFutureSchedule()`）は分母（`planned`）にも分子にも加算しない★
 *   （指示書V 不具合A）— `clean_timetables` には1週間分の予定がまとめて登録される（D-106）ので、
 *   まだ来ていない予定を分母に入れると稼働率・出発成功率・エラー発生率が実際より下振れする。
 *   `cleanLogs()`（`lib/db/index.ts`）・`prechecks()`・連続日数の算出と同じ扱いに揃えた。
 * ★★結果待ち（`isResultPending()`）の予定も、未来の予定と同じく数えない★★（予定回数にも入れない。
 *   表2 C11。ユーザー判断 2026-10-07。D-173）— レポートがまだ届いていないだけかもしれない清掃を
 *   未実施として分母・分子に入れると、当期の率が届くまでのあいだだけ下振れする。
 *   ★バケットは作る（決定1。行ごと捨てない）★。★判定に使うレポートの有無は `isNotExecuted` と同じ述語★。
 *
 * ★★ただし「行ごと捨てない」★★（決定1。2026-09-11 ユーザー確定）— この Map のキーが
 *   `facilityPerformance()` の当期行そのものになる（`lib/db/index.ts` の当期組み立て箇所）ため、
 *   未来の行しか無い施設のバケットを作らずに捨てると、その施設が一覧から消える
 *   （週の初め・月の初めに全施設が消える不具合として実測された）。
 *   ★範囲外の行だけ `continue` で捨て、未来の行は空のバケットだけ作って加算をスキップする★。
 *
 * ★★完了率は1回ごとの完了率（`runCompletionRate()`）の単純平均★★（D-155。期間の合計どうしの
 *   面積比は D-151 で廃止したまま）— 畳み方は ★「清掃1回 = 1票」★（根拠は `meanCleanRatio()` の docstring）。
 *   ここでは ★Σ（`cleanRatioSum`）と件数（`cleanRatioCount`）を積むだけ★で、割らない。
 *   ★1回ごとの完了率を足すのは「実施と数えた行 かつ 結果行が存在する」ときだけ★
 *   （`task_area = 0` の清掃は 0% として足す。P-5=B。D-158。★いまは件数が `executed` と同じ値になる★）—
 *   未実施を 0% として混ぜると、★稼働率で既に数えている失敗を完了率でも二重に数える★
 *   （旧実装の面積比でも、未実施行は `task_area` / `clean_area` に何も足さないので
 *   分母にも分子にも入っていなかった。★その扱いを引き継ぐ★）。
 * ★`clean_area` / `task_area` の合算は ★結果行があれば未実施判定と無関係に足す★ —
 *   総清掃面積（F-08。指示書AQ 1-3）は「実際に清掃した面積」なので、
 *   完了率の都合で落とさない（これも旧実装と同じ挙動）。
 *
 * @param mainRows `clean_timetables`（precheck=本清掃のみ）の全件
 * @param reportByTimetableId 本清掃id（文字列）→ `clean_task_reports` の1行。
 *   ★どの1行を採るか（`ended_at` ?? `started_at` が最新）は呼び出し側の責務★（指示書AQ 1-4。★担当C★）
 * @param isNotExecuted ★「未実施（＝出発失敗）か」を判定する述語★。
 *   ★★このファイルに規則を書かない★★ — 指示書AQ 1-1 の
 *   「★未実施 ＝ 対応する `clean_task_reports` の行が無い★」は ★担当C★ が
 *   `lib/db/clean-log-mapping.ts` に置く。ここは★受け取って呼ぶだけ★にして、
 *   ★規則が2箇所に散らない★ようにする（D-103 項1と同じ理由）。
 *   ★引数にした（TODO コメントにしなかった）理由★: 名前で参照すると担当Cの完成待ちになり、
 *   その間このファイルのテストが書けない。★述語を注入すれば依存が切れる★。
 * @param errorCountByMain `errorCountByMainTimetable()` の戻り値（本清掃idキー）
 * @param range `periodRange()` の戻り値（JST日付の [from, to]、両端含む）
 * @param now 「まだ来ていない予定」を判定する基準時刻。★必須引数（既定値を置かない）★ —
 *   省略できると「今日の日付」でテストが通ってしまい、境界値の検証にならないため
 */
export function aggregateCleanStatsByFacility(
  mainRows: readonly CleanStatsTimetableLike[],
  reportByTimetableId: ReadonlyMap<string, CleanStatsReportLike>,
  isNotExecuted: (report: CleanStatsReportLike | undefined) => boolean,
  errorCountByMain: ReadonlyMap<string, number>,
  range: { from: string; to: string },
  now: Date
): Map<number, CleanStatsBucket> {
  const result = new Map<number, CleanStatsBucket>();
  for (const row of mainRows) {
    // ★DBのDATETIMEには日本時間の壁時計値が入っている（TeamWorks第8回A2。指示書Y）ので、
    //   `jstIsoFromDb()` でJST日付の桁を作ってから比較する★
    //   （YYYY-MM-DDは辞書順=日付順。`lib/format/period.ts` の isCurrentPeriod() と同じ考え方）
    const jstDate = jstIsoFromDb(row.start_at).slice(0, 10);
    if (jstDate < range.from || jstDate > range.to) continue;

    const facilityId = Number(row.facility_id);
    const bucket = result.get(facilityId) ?? emptyCleanStatsBucket();

    // ★期間内にはあるが、まだ来ていない予定はバケットを作るだけで加算しない（決定1）★
    if (isFutureSchedule(fromDbJst(row.start_at), now)) {
      result.set(facilityId, bucket);
      continue;
    }

    const key = row.id.toString();
    const report = reportByTimetableId.get(key);
    const executed = !isNotExecuted(report);
    // ★結果待ちも未来の予定と同じく、バケットを作るだけで加算しない（表2 C11。D-173）★
    if (
      isResultPending({
        startAt: fromDbJst(row.start_at),
        endAt: fromDbJst(row.end_at),
        now,
        hasReport: executed,
      })
    ) {
      result.set(facilityId, bucket);
      continue;
    }
    // ★正常終了（稼働率の分子。P-6=A）は `isCompletedTask()` だけが決める★（status だけで決める。面積は見ない）
    const completed = executed && isCompletedTask(report);
    // ★完了率の分子・分母に入れるのは「実施と数えた行 かつ 結果行がある」ときだけ★
    //   （結果行が無ければ足す完了率が無い。0 を足すと「0%で清掃した」に化ける）。
    //   ★1回ごとの完了率は `runCompletionRate()` だけが決める★（D-155。行をそのまま渡す。D6）。
    const runRate = executed && report !== undefined ? runCompletionRate(report) : null;

    result.set(facilityId, {
      planned: bucket.planned + 1,
      executed: bucket.executed + (executed ? 1 : 0),
      completed: bucket.completed + (completed ? 1 : 0),
      taskArea: bucket.taskArea + (report?.task_area ?? 0),
      cleanArea: bucket.cleanArea + (report?.clean_area ?? 0),
      errorCount: bucket.errorCount + (errorCountByMain.get(key) ?? 0),
      cleanRatioSum: bucket.cleanRatioSum + (runRate ?? 0),
      cleanRatioCount: bucket.cleanRatioCount + (runRate === null ? 0 : 1),
    });
  }
  return result;
}

/**
 * `CleanStatsBucket` + 前期の4率 → `ReportKpi`（当期用）。
 *
 * ★稼働率・出発成功率・エラー発生率は `lib/judge/kpi.ts` の3関数に通す★（`CLAUDE.md` §4.2）。
 *   ★3つとも分母は予定回数（第11回 P-6。サマリと同じ）★。旧: エラー発生率の分母は実施回数だった。
 * ★★完了率だけは1回ごとの完了率の単純平均（`meanCleanRatio()`。`lib/judge/kpi.ts`）★★（D-155）—
 *   ★期間の合計どうしの面積比は使わない★。理由は `meanCleanRatio()` の docstring。
 * ★4指標とも丸めない生値を `KpiValue.value` に入れる（`CLAUDE.md` §4.3）★。
 */
export function kpiFromCleanStats(
  bucket: CleanStatsBucket,
  prev: SummaryRatios | undefined
): ReportKpi {
  return {
    operation_rate: toKpiValue(
      operationRate(bucket.completed, bucket.planned),
      prev?.operation_ratio ?? null
    ),
    launch_rate: toKpiValue(
      launchRate(bucket.executed, bucket.planned),
      prev?.launch_ratio ?? null
    ),
    completion_rate: toKpiValue(meanCleanRatio(bucket), prev?.clean_ratio ?? null),
    error_rate: toKpiValue(
      errorRate(bucket.errorCount, bucket.planned),
      prev?.error_ratio ?? null
    ),
  };
}

// ---------------------------------------------------------------- 連続問題日数（facilityPerformance用）

/**
 * `computeConsecutiveProblemDays()` に渡す1件（本清掃）の最小限の形。
 * ★`facility_id` を持たせているのは、期間内で「その施設の最終日」を選ぶため★。
 * ★`ConsecutiveInput`（`lib/db/clean-log-mapping.ts`）の分割キーも `facility_id` になった
 *   （指示書V 不具合B）ので、`ConsecutiveInput` はこの型が要求するフィールドをすべて持つ。
 *   `lib/db/index.ts` では詰め替えず `ConsecutiveInput[]` をそのまま渡している。
 */
export interface FacilityConsecutiveEntry {
  id: number;
  facility_id: number;
  /** ISO8601（+09:00）。`clean_timetables.start_at` 由来 */
  scheduled_at: string;
}

/**
 * 期間内で、その施設の「最終エントリ」（scheduled_at が最大の1件）を返す。
 * 1件も無ければ `undefined`（呼び出し側が0件やnullを組み立てる）。
 *
 * ★`consecutiveProblemDaysAtPeriodEnd()` の選び方の実体はここ1箇所★
 *   （D-103。呼び出し側で「最終エントリを自分で探す」コードを書かないこと）。
 * ★`last_problem_on`（指示書W。`ContinuousProblem`）の算出にも使う★ —
 *   連続日数だけでなく、日付そのものが要る場面はこちらを直接呼ぶ。
 *
 * @param entries 全期間・全施設の行（呼び出し側で施設を絞り込まない）
 * @param range `periodRange()` の戻り値（JST日付の [from, to]、両端含む）
 */
export function lastEntryInPeriod<T extends FacilityConsecutiveEntry>(
  entries: readonly T[],
  facilityId: number,
  range: { from: string; to: string }
): T | undefined {
  let latest: T | undefined;
  for (const entry of entries) {
    if (entry.facility_id !== facilityId) continue;
    const date = entry.scheduled_at.slice(0, 10);
    if (date < range.from || date > range.to) continue;
    if (!latest || entry.scheduled_at > latest.scheduled_at) latest = entry;
  }
  return latest;
}

/**
 * 施設別パフォーマンスの `consecutive_problem_days`（★着手前確認A案。D-103★）。
 *
 * ★`computeConsecutiveProblemDays()` は「その清掃ログの時点までの連続日数」を1件ごとに返す★
 *   （`cleanLogs()` と全く同じ関数・全く同じ入力の作り方。値の意味が一致する）。
 * `facilityPerformance()` の1行は「期間」を表すため、この関数で
 * ★「期間内でその施設の最終清掃ログ」を選び、その1件の連続日数を採用する★
 * （＝「その期間の最終日時点の連続日数」）。★選び方自体は `lastEntryInPeriod()` に委ねる★。
 *
 * ★期間内にその施設の清掃ログが1件も無ければ 0★（連続なしと同義に扱う。
 *   TeamWorksのサマリにこの値は存在しないため、0か算出済みの値かのどちらかになる。
 *   着手前確認のC案（`number | null` にして「未算出」を区別する）は不採用のため、
 *   ここでも null は使わない）。
 */
export function consecutiveProblemDaysAtPeriodEnd(
  entries: readonly FacilityConsecutiveEntry[],
  consecutiveById: ReadonlyMap<number, number>,
  facilityId: number,
  range: { from: string; to: string }
): number {
  const latest = lastEntryInPeriod(entries, facilityId, range);
  if (!latest) return 0;
  return consecutiveById.get(latest.id) ?? 0;
}

/**
 * 「その施設の全期間の行」から、`endDate` で終わる連続 `consecutiveDays` 日ぶんの日付を返す
 * （指示書W。`ContinuousProblem` の summary/launch_failed_days の材料）。
 *
 * ★★`facilityRows` には期間内だけでなく**その施設の全期間の行**を渡すこと★★ —
 *   ランは期間をまたぐ（前月から続いている連続が、期間内の行だけで畳むと途中で切れる）。
 *   `consecutive_problem_days` は全期間走査で出しているので、日数だけ合わせて
 *   ランの日付を期間内だけに絞ると `{m}`（`launchFailedDaysInRun()`）が過小になる。
 *
 * ★内部で `foldProblemDaysByDate()` を呼ぶ★（独自に日付を数え直さない。D-109の問題の再発防止）。
 * `endDate` が畳み込み後の日付に存在しなければ `[]`（呼び出し側は同じ行から取った日付を渡す
 * 契約なので、通常は起きない。例外にしない）。
 *
 * @param facilityRows その施設ぶんの `ConsecutiveInput[]`（全期間）
 * @param endDate `YYYY-MM-DD`。ランの最終日（`lastEntryInPeriod()` の日付）
 * @param consecutiveDays `computeConsecutiveProblemDays()` が返した連続日数
 */
export function problemRunDates(
  facilityRows: readonly ConsecutiveInput[],
  endDate: string,
  consecutiveDays: number
): string[] {
  const days = foldProblemDaysByDate(facilityRows);
  const endIndex = days.findIndex((d) => d.date === endDate);
  if (endIndex === -1) return [];
  const startIndex = Math.max(0, endIndex - consecutiveDays + 1);
  return days.slice(startIndex, endIndex + 1).map((d) => d.date);
}

/**
 * ラン（`problemRunDates()` の戻り値）のうち、出発失敗（未実施）があった日数を返す。
 *
 * ★出発失敗＝`departed === false`★（【未決1】案A。D-156。指示書AS 段階3-4）—
 *   ★`completion_rate === null` で数えないこと★。`lib/db/clean-log-mapping.ts` の不変条件は
 *   ★`departed === false` ⟺ `completion_rate === null`★（P-5=B で `task_area = 0` が 0% になり、両向きに戻った。D-158）。
 *   ★それでも `departed` で数える★（指示書AU D3）— 完了率の規則がまた変わっても、未実施の数え方が
 *   巻き込まれないため（1つの値を2つの意味に兼用しない）。
 * ★同じ日に「未実施の行」と「実施した行」が混在する場合、その日は出発失敗の日として
 *   1日だけ数える（OR。D-109 決定2 の同一日畳み込みと同じ規則）★。
 * ★ランの外の日は数えない★（`runDates` に含まれる日付だけを対象にする）。
 *
 * @param facilityRows その施設ぶんの `ConsecutiveInput[]`（全期間。`problemRunDates()` と同じ入力でよい）
 * @param runDates `problemRunDates()` の戻り値
 */
export function launchFailedDaysInRun(
  facilityRows: readonly ConsecutiveInput[],
  runDates: readonly string[]
): number {
  const runDateSet = new Set(runDates);
  const failedByDate = new Map<string, boolean>();
  for (const row of facilityRows) {
    const date = row.scheduled_at.slice(0, 10);
    if (!runDateSet.has(date)) continue;
    const isFailed = !row.departed;
    failedByDate.set(date, (failedByDate.get(date) ?? false) || isFailed);
  }
  let count = 0;
  for (const failed of failedByDate.values()) {
    if (failed) count += 1;
  }
  return count;
}

/**
 * `consecutive_problem_days` と `launch_failed_days` から `ContinuousProblem.summary` の
 * テンプレート文字列を選ぶ（指示書W 確定1・確定2・確定3）。
 *
 * ★戻り値は数値を埋めていないテンプレートのまま★（方式A。画面側が `{n}` `{m}` を差し込む）。
 * ★前提: `n >= 1` かつ `0 <= m <= n`★（`n <= 0` では呼ばれない。呼び出し側が行を作らない。決定6）。
 *
 * | 条件 | 戻り値 |
 * |---|---|
 * | 出発失敗の日が1日も無い（`m === 0`） | `SUMMARY_TEMPLATE_COMPLETION` |
 * | 全日が出発失敗（`m === n`） | `SUMMARY_TEMPLATE_LAUNCH_FAILED` |
 * | 混在（C案。2026-09-11 ユーザー確定） | `SUMMARY_TEMPLATE_MIXED` |
 *
 * ★★却下した2案★★: (a)「出発失敗を優先する」（D-111項2の決定4）— 直近に清掃を実施していても
 *   「出発失敗」と書くことになり事実と食い違う。(b)「完了率が△以下」で固定 — 出発失敗を隠す。
 */
export function continuousProblemSummary(
  consecutiveDays: number,
  launchFailedDays: number
): string {
  if (launchFailedDays === 0) return SUMMARY_TEMPLATE_COMPLETION;
  if (launchFailedDays === consecutiveDays) return SUMMARY_TEMPLATE_LAUNCH_FAILED;
  return SUMMARY_TEMPLATE_MIXED;
}

/**
 * 清掃ログの日付（`YYYY-MM-DD`。重複していてよい）から、週次+月次の期間キーを列挙する。
 *
 * ★★2026-09-13（指示書AC 段階5）以降、`continuousProblems()` はこの関数を呼ばない★★ —
 *   ★期間が引数（`ReportDbQuery`）で決まるようになったので、要求された1期間だけを
 *   組み立てる★（全期間ぶんの行を作ってからルート側で1期間を選ぶのをやめた）。
 *   ★★関数とテストは残してある★★ — 「日付の集合 → 週次+月次のキー」という規則は
 *   ★`weekOfMonth()` を必ず通す★という規律込みで固定する価値があり、
 *   ★全期間ぶんの行が要る用途（バッチ・検証スクリプト）が出たときの受け皿になるため。
 *   ★使うときは必ずこの関数を経由し、「1日から7日ごと」と書き直さないこと★。
 *
 * ★`continuousProblems()` に対応するサマリテーブルが無いため（D-102項4）、
 *   `facilityPerformance()`（サマリ行から期間キーを列挙。`lib/db/index.ts`）とは違い、
 *   詳細行の日付そのものから列挙する必要がある★。
 * ★★週番号は必ず `weekOfMonth()` に通す★★ — 月跨ぎ週の帰属を知っているのは
 *   `weekOfMonth()` だけ（D-071 / `CLAUDE.md` §4.7）。自分で「1日から数えて7日ごと」と
 *   書かないこと。
 * ★`todayJst()` は呼ばない★ — 当期を特別扱いしない（決定2。確定期間も当期も同じ処理で作る）。
 * ★年次（`month=0 && week=0`）のキーは作らない★ — この関数は常に実在する日付から
 *   `weekOfMonth()` で年月を導くため、`month=0` は構造的に発生しない。
 *   ★2026-09-30 に年次を解禁した（D-151）が、この関数は変えていない★ — ★アプリ内に呼び出し元が
 *   無い★（定義とテストのみ）ため。年次キーが要る呼び出し元を足すときに、ここも年次を作るよう直すこと。
 *   旧: 「P1では読まない。D-072項4」— D-151 で破棄。
 *
 * @returns `year` → `month` → `week`（`week:0` の月次が先頭）の昇順。重複なし
 */
export function reportPeriodKeysFromDates(
  dates: readonly string[]
): ReportPeriodKey[] {
  const byKey = new Map<string, ReportPeriodKey>();
  for (const date of dates) {
    const { year, month, week } = weekOfMonth(date);
    const monthly: ReportPeriodKey = { period: "monthly", year, month, week: 0 };
    const weekly: ReportPeriodKey = { period: "weekly", year, month, week };
    byKey.set(periodMapKey(monthly.period, monthly.year, monthly.month, monthly.week), monthly);
    byKey.set(periodMapKey(weekly.period, weekly.year, weekly.month, weekly.week), weekly);
  }
  return [...byKey.values()].sort(
    (a, b) => a.year - b.year || a.month - b.month || a.week - b.week
  );
}

/**
 * 1期間ぶんの `ContinuousProblem[]` を組み立てる（指示書W 段階5）。
 *
 * ★★DB を読む `continuousProblems()`（`lib/db/index.ts`）の中に直接書くと、
 *   「連続0日は行を作らない」「ロボット0台の施設も出す」「L1もデータ層は返す」を
 *   テストできない★★（禁止事項「テストをDB依存にしない」）ため、純粋関数に切り出してある。
 *   `continuousProblems()` は「DBから材料を集めてこの関数を呼ぶだけ」にすること。
 *
 * ★組み立ての順序（この順で）★:
 *   1. `facilityNameById` を回す（`entries` を回さない — 名前の無い施設の行を作らないため。
 *      `entries` にあるが `facilityNameById` に無い施設idは無視する）
 *   2. `consecutiveProblemDaysAtPeriodEnd()` で期末時点の連続日数を求め、`<= 0` なら `continue`
 *   3. `judgeEscalationLevel()` で L1/L2/L3 を求め、`null`（0日）なら `continue`
 *      （★`as` キャストや `?? "L1"` で握り潰さない。決定6★）
 *   4. `lastEntryInPeriod()` で期間内の最終エントリを取得。無ければ `continue`
 *      （2 で0日を弾いているので通常は起きないが、`!` や `as` は使わない）
 *   5. `facilityRows = entries.filter(e => e.facility_id === facilityId)`
 *      ★★その施設の**全期間**の行を渡す★★ — ランは期間をまたぐ（前月から続く連続を
 *      期間内だけで畳むと途中で切れ、`launch_failed_days` が過小になる）
 *   6. `problemRunDates()` でランの日付配列を求める
 *   7. `launchFailedDaysInRun()` で `{m}` を求める
 *   8. `continuousProblemSummary()` で summary テンプレートを選ぶ
 *   9. 行を積む
 *
 * ★ロボット0台の施設を除外しない（決定5）★ — `facilityNameById` は呼び出し側
 *   （`prismaSource.continuousProblems()`）が `robots` を join せずに作る。この関数は
 *   `facilityNameById` にある施設をそのまま対象にするだけで、robots の有無を一切見ない。
 * ★「2日以上」の絞り込み・並べ替えはこの関数の責務ではない★（決定4。`lib/reports/query.ts` の仕事）。
 *   戻りの順序は `facilityNameById` の反復順（＝ Map の挿入順）のまま。
 *
 * @param entries 過去の行のみ・全施設・全期間の `ConsecutiveInput[]`
 * @param consecutiveById `computeConsecutiveProblemDays()` の戻り値
 * @param facilityNameById 施設id → 施設名（★ロボット0台の施設も入っている★）
 * @param range `periodRange()` の戻り値（JST日付の [from, to]、両端含む）
 */
export function continuousProblemsInPeriod(
  entries: readonly ConsecutiveInput[],
  consecutiveById: ReadonlyMap<number, number>,
  facilityNameById: ReadonlyMap<number, string>,
  range: { from: string; to: string }
): ContinuousProblem[] {
  const result: ContinuousProblem[] = [];
  for (const [facilityId, facilityName] of facilityNameById) {
    const days = consecutiveProblemDaysAtPeriodEnd(entries, consecutiveById, facilityId, range);
    if (days <= 0) continue;

    const level = judgeEscalationLevel(days);
    if (level === null) continue;

    const latest = lastEntryInPeriod(entries, facilityId, range);
    if (!latest) continue;

    const facilityRows = entries.filter((e) => e.facility_id === facilityId);
    const runDates = problemRunDates(facilityRows, latest.scheduled_at.slice(0, 10), days);
    const launchFailedDays = launchFailedDaysInRun(facilityRows, runDates);
    const summary = continuousProblemSummary(days, launchFailedDays);

    result.push({
      facility_id: facilityId,
      facility_name: facilityName,
      consecutive_problem_days: days,
      escalation_level: level,
      last_problem_on: latest.scheduled_at.slice(0, 10),
      summary,
      launch_failed_days: launchFailedDays,
    });
  }
  return result;
}

/**
 * `ContinuousProblem[]` に★表示上限★をかける（指示書AF 段階5-2）。★純粋関数★。
 *
 * ★★呼ぶ場所は「絞り込み → 並べ替え → 切り出し」の**後**★★ —
 *   `sortContinuousProblems()` は `consecutive_problem_days` の降順で並べるので、
 *   ★先に頭打ちにすると上限に達した施設どうしの順序が潰れます★
 *   （45日 / 31日 が両方 30日になり、元の重さの差が消える。指示書AF §G 落とし穴2）。
 *   `filterContinuousProblems()` の「2日以上」も生値で判定させる。
 *
 * ★★`escalation_level` は触らない★★ — L1〜L3 は★上限をかける前の生値★で判定済み
 *   （`CLAUDE.md` §4.3 / 指示書AF 禁止事項9）。ここで作り直すと
 *   「3日以上と出ているのに Lv3 が出ない」になる。
 *
 * ★上限に達した行は `launch_failed_days` を**落とす**★（指示書AF §B-5）:
 *   `d-watch-api.yaml` が `0 <= launch_failed_days <= consecutive_problem_days` を定めており、
 *   `n` を頭打ちにするとこの不等式が壊れる（実際45日・うち40日が出発失敗 → `n=30` で `m=40 > n`）。
 *   `min(m, n)` に丸めるのは「直近n日のうち何日が出発失敗か」の捏造になる。
 *   `launch_failed_days` はもともと任意項目なので、省略しても契約違反にならない。
 *
 * @param items ★絞り込み・並べ替え・切り出し済み★の配列
 * @param maxDays 表示上限（`loadConsecutiveDaysMax()` の戻り値を渡す。既定値を直書きしない）
 */
export function capContinuousProblems(
  items: readonly ContinuousProblem[],
  maxDays: number
): ContinuousProblem[] {
  return items.map((item) => {
    const { days, capped } = capConsecutiveDays(item.consecutive_problem_days, maxDays);
    if (!capped) {
      // ★他のフィールドは一切作り直さない★（summary も launch_failed_days もそのまま）
      return { ...item, consecutive_problem_days_capped: false };
    }
    // ★`launch_failed_days` はキーごと落とす★（`undefined` を入れるのではなく列挙しない。
    //   JSON に `"launch_failed_days": null` が出ないようにするため）
    return {
      facility_id: item.facility_id,
      facility_name: item.facility_name,
      consecutive_problem_days: days,
      consecutive_problem_days_capped: true,
      // ★生値で判定済みの結果をそのまま運ぶ（判定し直さない）★
      escalation_level: item.escalation_level,
      last_problem_on: item.last_problem_on,
      summary: cappedSummaryTemplate(item.summary),
    };
  });
}

/**
 * 上限で頭打ちになったときの summary テンプレートを選ぶ（`capContinuousProblems()` 専用）。
 *
 * ★元のテンプレートからの1対1の差し替え★ — 日数と出発失敗日数の関係は変わらないので、
 *   どのテンプレートが選ばれていたかだけを見れば足りる（`continuousProblemSummary()` を
 *   もう一度呼ぶ必要は無い）。★未知の文字列はそのまま返す★（作り話をしない）。
 */
function cappedSummaryTemplate(summary: string): string {
  if (summary === SUMMARY_TEMPLATE_COMPLETION) return SUMMARY_TEMPLATE_CAPPED_COMPLETION;
  if (summary === SUMMARY_TEMPLATE_LAUNCH_FAILED) return SUMMARY_TEMPLATE_CAPPED_LAUNCH_FAILED;
  if (summary === SUMMARY_TEMPLATE_MIXED) return SUMMARY_TEMPLATE_CAPPED_MIXED;
  return summary;
}

// ---------------------------------------------------------------- エラー種別内訳

/** `facility_error_summaries` 1行ぶんの最小限の形（`customer_error_summaries` は使わない） */
export interface ErrorSummaryRowLike {
  year: number;
  month: number;
  week: number;
  /** ★DBの生値。7分類へのマッピングも日本語化もしない（D-077/D-088）★ */
  error_type: string;
  error_count: number;
}

/**
 * 件数の `Map`（`error_type` → 件数）→ `ErrorBreakdownItem[]`。
 *
 * ★`type` と `label` の両方に同じ生値を入れる★（D-077/D-088。7分類にも日本語にも変換しない）。
 * ★`rate` は丸めない生値★（CLAUDE.md §4.3）。★分母はこの Map 内の全件数の合計★
 *   （`reduce` で出す。合計を定数に置かない。`lib/fixtures/reports.ts:478` と同じ作法）。
 * 件数が1件も無ければ空配列（該当0件の表示。`errorBreakdownEmpty` と同じ扱い）。
 */
export function errorBreakdownItemsFromCounts(
  counts: ReadonlyMap<string, number>
): ErrorBreakdownItem[] {
  const total = [...counts.values()].reduce((sum, count) => sum + count, 0);
  return [...counts].map(([type, count]) => ({
    type,
    label: type,
    count,
    rate: total === 0 ? 0 : (count / total) * 100,
  }));
}

/**
 * `facility_error_summaries` の全行から、期間ごとに同一 `error_type` を全施設ぶん足し上げる
 * （★facility版で確定。D-102項4の解決 — `facilityPerformance()` と粒度を揃える★）。
 *
 * ★履歴から再計算しない（サマリの `error_count` をそのまま合算するだけ。D-102）★。
 * ★年次（`month===0 && week===0`）の行もそのまま渡してよい★（2026-09-30 に年次を解禁。D-151）。
 * 粒度の判別は `periodOfSummaryRow()` が `month` も見て行うので、年次が月次に化けることはない。
 * 旧: 「呼び出し側で年次を除外してから渡すこと（P1では読まない。D-072項4）」— D-151 で破棄。
 */
export function errorBreakdownRowsFromSummary(
  rows: readonly ErrorSummaryRowLike[]
): Array<ReportPeriodKey & { items: ErrorBreakdownItem[] }> {
  const countsByPeriodKey = new Map<string, Map<string, number>>();
  const periodInfoByKey = new Map<string, ReportPeriodKey>();

  for (const row of rows) {
    const period = periodOfSummaryRow(row);
    const key = periodMapKey(period, row.year, row.month, row.week);
    if (!periodInfoByKey.has(key)) {
      periodInfoByKey.set(key, { period, year: row.year, month: row.month, week: row.week });
    }
    const byType = countsByPeriodKey.get(key) ?? new Map<string, number>();
    byType.set(row.error_type, (byType.get(row.error_type) ?? 0) + row.error_count);
    countsByPeriodKey.set(key, byType);
  }

  const result: Array<ReportPeriodKey & { items: ErrorBreakdownItem[] }> = [];
  for (const [key, byType] of countsByPeriodKey) {
    const periodInfo = periodInfoByKey.get(key);
    // ★periodInfoByKeyはcountsByPeriodKeyと同じループで両方セットしているので必ず存在する★
    if (!periodInfo) continue;
    result.push({ ...periodInfo, items: errorBreakdownItemsFromCounts(byType) });
  }
  return result;
}

/** `robot_error_reports` 1行ぶんの最小限の形（当期のその場集計用） */
export interface ErrorReportLike extends PrecheckDetectedAtSource {
  /** ★DBの生値。7分類へのマッピングも日本語化もしない（D-077/D-088）★ */
  error_type: string;
}

/**
 * 当期（詳細テーブル）のエラー内訳を ★本清掃行を指すエラーだけ★ `error_type` ごとに数える。
 *
 * ★★分子の集合は `errorCountByMainTimetable()` と同じ★★（決定2）—
 *   同じレポート画面（F-06）に定義の違う2つの数字を並べないため。
 *   ★事前チェック行を指すもの / `null` / dangling は数えない★（TeamWorks 第8回 A7・決定3）。
 *
 * ★★期間帰属は「そのエラーが指す本清掃行の `start_at` の JST 日付」★★（決定7）—
 *   エラー率の分母は清掃予定回数（P-6=B。`CLAUDE.md` §4.2）なので、分子も予定（本清掃）を基準にする。
 *   ★`errored_at` 基準ではない★（深夜清掃が日をまたぐと分子と分母が別の期間に入るため）。
 *   `reportKpis()` / `facilityPerformance()` は `aggregateCleanStatsByFacility()` が
 *   本清掃行を期間で絞ってからエラー件数を足すので ★すでにこの帰属★。そちらに揃える向き。
 * ★`jstIsoFromDb()` で日本時間の壁時計値に補正してから日付の桁を取る★
 *   （TeamWorks 第8回 A2。指示書Y）。`YYYY-MM-DD` は辞書順＝日付順。
 * ★`type` / `label` は生値のまま。7分類・日本語への変換はしない（D-077 / D-088）★
 */
export function countMainErrorTypesInRange(
  errorReports: readonly (ErrorReportLike & { clean_timetable_id: bigint | null })[],
  mainStartAtById: ReadonlyMap<string, Date>,
  range: { from: string; to: string }
): Map<string, number> {
  const counts = new Map<string, number>();
  for (const report of errorReports) {
    if (report.clean_timetable_id === null) continue;
    const startAt = mainStartAtById.get(report.clean_timetable_id.toString());
    // ★事前チェック行を指すもの・dangling はここで落ちる（肯定条件の自然な帰結）★
    if (startAt === undefined) continue;
    const jstDate = jstIsoFromDb(startAt).slice(0, 10);
    if (jstDate < range.from || jstDate > range.to) continue;
    counts.set(report.error_type, (counts.get(report.error_type) ?? 0) + 1);
  }
  return counts;
}