-- 主管重排(调整各客服在手的单)的操作记录 —— plan_event_logs.operation_id
--
-- 【为什么要这一列】重排**不建批次**(单子的 assignment_id 一律不动,否则原批的
--   planned 会静默缩水 —— 见 schema.prisma 里 assignment_id 那段红字)。
--   但"这 22 条属于同一次重排"必须记得住:审计、提交幂等、将来撤销一次重排,
--   三条路都要按它筛。本表的规矩是「要按它筛就该立柱」。
--
-- 【⛔ 为什么不复用 assignment_id】那一列没有外键(裸 uuid),物理上塞得进重排 id ——
--   但 ledgerStatsByAssignment / handledByAssignment 都在 `WHERE assignment_id IN (…)`
--   上出数。两个 id 空间混一列,迟早串台,而且不报错。
--
-- 【为什么普通 CREATE INDEX 就够,不用 CONCURRENTLY】
--   生产实测(2026-08-20)plan_event_logs 只有 2,298 行 / 1 MB —— 建索引是毫秒级,
--   ACCESS EXCLUSIVE 锁的时间可以忽略。
--   ⚠️ 这张表是 append-only 账本,会随分配功能铺开而增长。**将来再给它加索引时
--     先量一遍行数**:上到百万级就必须换成 CONCURRENTLY,而 CONCURRENTLY 要求
--     整份 migration.sql 只有一条语句(见 20260802150000 那份的说明)。

-- AlterTable
ALTER TABLE "plan_event_logs" ADD COLUMN "operation_id" UUID;

-- CreateIndex
CREATE INDEX "plan_event_logs_operation_id_idx" ON "plan_event_logs"("operation_id");
