@gadmin2n/schematics 0.0.136 → 0.0.137

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/TODO.md

@@ -1,152 +0,0 @@
-# Temporal Worker — 后续改造 TODO
-
-本文档汇总 worker 在"重启 / 升级"场景下还可以做的改造。
-已完成项不在此列；当前已完成：
-
-- ✅ DSL 图环检测（`dsl-workflow.ts` `executeGraph` 加迭代上限）
-- ✅ Outbox Poller 事务边界（每行一个事务 + 确定性 workflowId 幂等保护）
-- ✅ Graceful Shutdown（`worker.shutdown()` + `outboxPoller.stop()` + health server）
-- ✅ Outbox 重试时 t_workflow_instance 残留行 —— `WorkflowInstance` 加 `sourceOutboxId`，`(workflow_id, source_outbox_id)` 复合 UNIQUE，`matchAndTrigger` 改为 `INSERT ... ON CONFLICT DO UPDATE`
-- ✅ DSL 提交时 DAG 校验（`dsl-validate.util.ts` + 在 `WorkflowService.publish()` 调用，循环图 / 缺 trigger / 重复 id / 悬空 edge 全部 400）
-- ✅ Activity Timeout 分级（`httpActs` / `dbActs` / `notifyActs` / `codeActs` / `reportActs` 各自独立 timeout & retry policy）
-
----
-
-## P0 — Activity 缺少 Heartbeat 与 Cancellation 响应
-
-**位置**：`src/activities/http-request.ts`、`db-query.ts`、`db-execute.ts`、`code-execute.ts`
-
-**问题**：Activity 不调 `Context.current().heartbeat()`，也不监听 `Context.current().cancellationSignal`。
-Worker 收到 SIGTERM 后 `worker.shutdown()` 会向 in-flight Activity 发 cancel，但当前实现完全不响应，
-必须等 `startToCloseTimeout: 60s` 自然超时。极端场景（HTTP 卡住、code-execute vm timeout 失效）
-会一直占用 worker 进程到 grace period 结束被 SIGKILL，Temporal 端再等心跳超时才能重派。
-
-**改造示例（http-request）**：
-
-```ts
-import { Context } from '@temporalio/activity';
-
-export async function httpRequest(input: HttpRequestInput): Promise<HttpRequestOutput> {
-  const ctx = Context.current();
-  const controller = new AbortController();
-  ctx.cancellationSignal.addEventListener('abort', () => controller.abort());
-
-  const heartbeatTimer = setInterval(() => ctx.heartbeat(), 5_000);
-  try {
-    const response = await axios({ ...axiosConfig, signal: controller.signal });
-    return { status: response.status, data: response.data, headers: response.headers as any };
-  } finally {
-    clearInterval(heartbeatTimer);
-  }
-}
-```
-
-**db-query / db-execute**：把 PG client 的 query 包成可取消（pg 8.x 支持 `client.cancel()`），
-并在每条长查询前 `ctx.heartbeat()`。
-
-**code-execute**：vm 不支持外部中断，至少应在 `runOnceForEach` 每个 item 之间检查 `ctx.cancellationSignal.aborted` 并提前 return。
-
----
-
-## P1 — Worker Build IDs (Workflow Versioning)
-
-**问题**：`src/index.ts` 的 `Worker.create({...})` 没有传 `buildId`。
-所有版本的 worker 都从同一 task queue 拉 task，包括老 workflow 的 history replay。
-`dsl-workflow.ts` 是动态解释器，但解释器自身的代码改动也会破坏 determinism：
-
-- 改 BFS 调度顺序（`queue.shift`）→ 老 workflow replay 失败
-- 改 `for_each` 的 batch concurrency 处理 → 老 workflow replay 失败
-- 改 `parallel` 的 `Promise.all` vs `Promise.race` → 老 workflow replay 失败
-
-**改造**：
-
-```ts
-const worker = await Worker.create({
-  connection,
-  namespace: config.temporal.namespace,
-  taskQueue: config.temporal.taskQueue,
-  workflowsPath: require.resolve('./workflows/dsl-workflow'),
-  activities,
-  buildId: process.env.WORKER_BUILD_ID || require('../package.json').version,
-  useVersioning: true,
-});
-```
-
-部署时还需通过 Temporal CLI 把新 buildId 标记为 default：
-
-```bash
-temporal task-queue versioning add-new-default \
-  --task-queue workflow-execution \
-  --build-id v1.2.0
-```
-
-> Temporal 1.21+ 支持 Worker Build IDs；1.24+ 有更易用的 Worker Deployment API，可一并评估。
-
----
-
-## P1 — `for_each` 节点不响应 Cancel
-
-**位置**：`src/workflows/dsl-workflow.ts` 的 `for_each` 分支（约 L319-355）
-
-**问题**：item 数量很大时（比如 1000 条），`for (let i = 0; i < items.length; i += concurrency)`
-循环中途用户/系统 cancel 不会立即退出，必须等循环跑完。
-
-**改造**：每个 batch 前检查 cancel 标志：
-
-```ts
-for (let i = 0; i < items.length; i += concurrency) {
-  if (isCancelled()) throw new CancellationScope().cancel;   // ← 加这一行
-  const batch = items.slice(i, i + concurrency);
-  // ...
-}
-```
-
----
-
-## P2 — Activity Timeout 业务级覆盖
-
-**当前状态**：dsl-workflow.ts 已按职责类别拆出 `httpActs` / `dbActs` / `notifyActs` / `codeActs` / `reportActs`，
-各自 timeout 和 retry 独立。但仍是**类别级**配置，业务在 DSL 里指定 `input.timeout` 只透传到 axios/vm 内部，
-没法影响 Temporal Activity 的 `startToCloseTimeout`。
-
-**进一步改造**：通过 `Context.current().heartbeat()` + 业务级 timeout 透传，让 DSL 的 `config.timeoutSec`
-也能影响 Activity 调度层。例如：
-
-```ts
-case 'http_request': {
-  const proxyOpts = config.timeoutSec
-    ? { startToCloseTimeout: `${config.timeoutSec}s`, retry: { maximumAttempts: 3 } }
-    : undefined;
-  const httpProxy = proxyOpts
-    ? proxyActivities<...>({ ...proxyOpts })
-    : httpActs;
-  return { output: await httpProxy.httpRequest(config as any) };
-}
-```
-
-**注意**：Workflow 内 `proxyActivities` 是确定性配置，运行时动态创建会破坏 replay。
-更稳妥的做法是预先创建 N 个 timeout 档（如 30s / 120s / 600s），DSL 指定档位而非任意数值。
-
----
-
-## P3 — 进程级兜底 + Health Server 强断
-
-**位置**：`src/index.ts`
-
-```ts
-// 缺崩溃日志兜底
-process.on('uncaughtException', (err) => {
-  console.error('[Worker] uncaughtException:', err);
-  void shutdown('uncaughtException');
-  setTimeout(() => process.exit(1), 30_000).unref();
-});
-process.on('unhandledRejection', (reason) => {
-  console.error('[Worker] unhandledRejection:', reason);
-});
-
-// healthServer.close() 不会主动断 keep-alive 连接，K8s probe 长连接会拖慢退出
-await new Promise<void>((resolve) => {
-  healthServer.close(() => resolve());
-  healthServer.closeAllConnections?.();   // Node 18.2+
-});
-```

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/config/development-sql.yaml

@@ -1,5 +0,0 @@
-# Temporal dynamic configuration for development
-# See: https://docs.temporal.io/references/dynamic-configuration
-system.forceSearchAttributesCacheRefreshOnRead:
-  - value: true
-    constraints: {}

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/docker-compose.yml

@@ -1,25 +0,0 @@
-services:
-  temporal:
-    image: temporalio/auto-setup:latest
-    ports:
-      - "7233:7233"
-    environment:
-      - DB=postgres12
-      - DB_PORT=5432
-      - POSTGRES_USER=kavenma
-      - POSTGRES_PWD=kavenma
-      - POSTGRES_SEEDS=host.docker.internal
-      - DYNAMIC_CONFIG_FILE_PATH=config/dynamicconfig/development-sql.yaml
-    volumes:
-      - ./config:/etc/temporal/config/dynamicconfig
-    extra_hosts:
-      - "host.docker.internal:host-gateway"
-
-  temporal-ui:
-    image: temporalio/ui:latest
-    ports:
-      - "8080:8080"
-    environment:
-      - TEMPORAL_ADDRESS=temporal:7233
-    depends_on:
-      - temporal

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/package.json

@@ -1,13 +0,0 @@
-{
-  "name": "gadmin-temporal",
-  "private": true,
-  "scripts": {
-    "up": "docker compose up -d",
-    "down": "docker compose down",
-    "logs": "docker compose logs -f",
-    "worker:install": "cd worker && npm install",
-    "worker:dev": "cd worker && npm run dev",
-    "worker:build": "cd worker && npm run build",
-    "worker:start": "cd worker && npm start"
-  }
-}

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/worker/.dockerignore

@@ -1,12 +0,0 @@
-node_modules
-dist
-.env.*
-.git
-*.log
-.claude
-.vscode
-.idea
-tests
-vitest.config.ts
-*.md
-coverage

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/worker/.env

@@ -1,7 +0,0 @@
-# Temporal Worker Environment
-TEMPORAL_ADDRESS=localhost:7233
-TEMPORAL_NAMESPACE=default
-TEMPORAL_TASK_QUEUE=workflow-execution
-
-# Database (same as server)
-DATABASE_URL=postgresql://kavenma:kavenma@127.0.0.1:5432/gadmin_demo?schema=public

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/worker/Dockerfile

@@ -1,79 +0,0 @@
-# syntax=docker/dockerfile:1
-#
-# Temporal Worker 镜像
-#
-# Build context: temporal/worker/
-#   docker build -t gadmin-workflow-worker -f temporal/worker/Dockerfile temporal/worker
-#
-# Worker 通过 require.resolve('./workflows/dsl-workflow') 在运行时加载已编译的
-# workflow JS，无需 bundleWorkflowCode 预打包。
-#
-# 为什么用 node:20-slim 不用 node:20-alpine：
-#   @temporalio/core-bridge 的 native binding 是 glibc 二进制。alpine 用 musl libc，
-#   会在 require 时报 "Error relocating ...: __register_atfork: symbol not found" 直接崩。
-#   slim 是 debian-bookworm-slim 基底，glibc，体积也只比 alpine 大几十 MB。
-
-# ─── 阶段 1：构建 ────────────────────────────────────────────
-FROM node:20-slim AS builder
-
-WORKDIR /app
-
-# 禁止 husky 在无 .git 环境下报错
-ENV HUSKY=0
-
-# 先复制依赖描述文件，源码未变时此层可复用缓存
-COPY package.json yarn.lock ./
-
-# 安装全量依赖（含 devDependencies，用于 TypeScript 编译）
-RUN --mount=type=cache,target=/root/.yarn \
-    yarn install --frozen-lockfile
-
-# 复制源码与 tsconfig
-COPY tsconfig.json ./
-COPY src/ ./src/
-
-# 编译 TypeScript → dist/
-RUN yarn build
-
-# ─── 阶段 2：运行 ────────────────────────────────────────────
-FROM node:20-slim AS runner
-
-# 时区：与 server 保持一致。debian-slim 不预装 tzdata，需要 apt 装一下。
-RUN apt-get update && \
-    apt-get install -y --no-install-recommends tzdata && \
-    rm -rf /var/lib/apt/lists/* && \
-    ln -snf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
-    echo "Asia/Shanghai" > /etc/timezone
-ENV TZ=Asia/Shanghai
-
-WORKDIR /app
-
-# 优雅关闭：让 Node 进程（PID 1）直接收到 SIGTERM 后调用 worker.shutdown()
-STOPSIGNAL SIGTERM
-
-ENV HUSKY=0 \
-    NODE_ENV=production
-
-# 先复制依赖描述文件
-COPY --chown=node:node package.json yarn.lock ./
-
-# 只安装 production 依赖，大幅减少镜像体积
-RUN --mount=type=cache,target=/root/.yarn \
-    yarn install --production --frozen-lockfile
-
-# 从构建阶段复制编译产物（不带源码）
-COPY --from=builder --chown=node:node /app/dist ./dist
-
-# 切换到非 root 用户（node 镜像内置 uid/gid 1000）
-USER node
-
-# Worker 仅出站连接 Temporal Server (7233) 与 PostgreSQL；额外暴露 :8081 供 K8s probe 访问 health 端点
-EXPOSE 8081
-
-# 容器健康检查：调用 worker 内置的 /health/live 端点。
-# debian-slim 不带 wget/curl，用 node 自带 http 模块代替（零额外依赖、~10ms 开销）。
-HEALTHCHECK --interval=30s --timeout=5s --start-period=15s --retries=3 \
-    CMD node -e "require('http').get('http://127.0.0.1:8081/health/live',r=>process.exit(r.statusCode===200?0:1)).on('error',()=>process.exit(1))" || exit 1
-
-# exec form 确保 node 作为 PID 1 直接接收 SIGTERM
-CMD ["node", "dist/index.js"]

package/dist/lib/application/files/gadmin2-game-angle-demo/temporal/worker/GRACEFUL-DEPLOYMENT.md

@@ -1,270 +0,0 @@
-# Temporal Worker — Graceful Deployment 方案
-
-本文档描述 Temporal Worker 在 K8s 环境下零停机滚动升级的方案，与 `server/GRACEFUL-DEPLOYMENT.md` 形成姊妹文档。Worker 与 server 的区别在于：
-
-- **不直接接收用户流量**（不挂 Service / Ingress），所以 Endpoints 摘除一项不适用；
-- **持有的工作单元更长**：单个 Activity / Workflow Task 可能跑数十秒到几分钟；
-- **是 Temporal task queue 的消费者**：被 SIGKILL 后，Temporal Server 会等到 ScheduleToCloseTimeout / 心跳超时才把任务返还队列，造成延迟与重复执行风险。
-
----
-
-## 1. 整体时序
-
-```
-K8s 发起 Pod 删除（Deployment rolling update）
-    │
-    └─► 执行 lifecycle.preStop hook
-         │
-         └─► sleep 5s（让 readinessProbe 失败 + outbox poller 当前批次有缓冲）
-              │
-              └─► 发送 SIGTERM 给容器主进程（node, PID 1）
-                   │
-                   ├─► process.on('SIGTERM') handler 触发
-                   │    ├─► worker.shutdown()        // 停止接取新 task
-                   │    ├─► outboxPoller.stop()      // 不再调度下一次 poll
-                   │    │     ├─► 等待当前 in-flight poll 完成
-                   │    │     ├─► pg.end()
-                   │    │     └─► temporalConn.close()
-                   │    └─► healthServer.close()     // 停止响应 K8s probe
-                   │
-                   └─► worker.run() 等待所有 in-flight Activity/Workflow Task 完成后 resolve
-                        └─► connection.close() → 进程退出
-
-    ═══════════════════════════════════════════════════════════════
-    terminationGracePeriodSeconds（300s）超时后 → 强制 SIGKILL
-```
-
-**关键差异：** Worker 不需要 "等 iptables 同步" 那种延迟，preStop sleep 主要起两个作用：
-1. 让 `/health/ready` 提前 503，K8s probe 能察觉副本即将下线（如有上层调度策略可参考）；
-2. 给 outbox poller 当前批次（已 `UPDATE ... SET processed=TRUE` 但还在 `temporalClient.workflow.start` 中的事件）多留几秒缓冲。
-
----
-
-## 2. 代码改动
-
-### 2.1 `src/index.ts` — 主流程
-
-```ts
-process.on('SIGTERM', () => void shutdown('SIGTERM'));
-process.on('SIGINT',  () => void shutdown('SIGINT'));
-
-await worker.run();          // 阻塞直到 worker.shutdown() 被调用 + tasks drain
-await connection.close();    // worker.run() resolve 之后再关连接
-```
-
-`shutdown()` 内部：
-1. `worker.shutdown()` — 同步调用，使 worker 不再接取新 task；
-2. `outboxPoller.stop()` — 取消下一次 setTimeout，等当前 poll 完成，关 PG / Temporal client；
-3. `healthServer.close()` — 停止响应 probe。
-
-### 2.2 `src/outbox-poller.ts` — 暴露 stop()
-
-`startOutboxPoller()` 现在返回：
-
-```ts
-interface OutboxPollerHandle {
-  stop(): Promise<void>;
-}
-```
-
-`stop()` 行为：
-- 设置 `stopped = true`，下一次循环不再被调度；
-- 若处于 setTimeout 等待中：`clearTimeout` 立即取消；
-- 若处于 in-flight poll 中：等当前 poll 完成（含本轮所有事件处理）；
-- 关闭 PG client 与 Temporal Connection。
-
-### 2.3 `src/index.ts` — Health 端点
-
-| 端点 | 用途 | 行为 |
-|------|------|------|
-| `GET /health/live` | K8s livenessProbe | 进程存活始终 200 |
-| `GET /health/ready` | K8s readinessProbe | `isReady && !isShuttingDown` 才 200，否则 503 |
-
-监听端口由 `HEALTH_PORT` 环境变量控制，默认 `8080`。
-
-### 2.4 `Dockerfile`
-
-```dockerfile
-STOPSIGNAL SIGTERM            # 与 K8s 默认信号一致
-EXPOSE 8080                   # health 端口
-HEALTHCHECK --interval=30s --timeout=5s --start-period=15s --retries=3 \
-    CMD wget -qO- http://127.0.0.1:8080/health/live || exit 1
-CMD ["node", "dist/index.js"] # exec form：node 作为 PID 1 直接收 SIGTERM
-```
-
----
-
-## 3. K8s Deployment 配置
-
-```yaml
-apiVersion: apps/v1
-kind: Deployment
-metadata:
-  name: gadmin-workflow-worker
-spec:
-  # ─── 滚动升级策略 ───────────────────────────────────────────
-  strategy:
-    type: RollingUpdate
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 1   # Worker 不直接接流量，可以容忍短暂少 1 个副本
-
-  template:
-    spec:
-      # ─── 优雅关闭宽限期 ─────────────────────────────────────
-      terminationGracePeriodSeconds: 300
-      # 给 worker 足够时间完成：
-      # - 当前正在执行的 Activity / Workflow Task（最长可能数分钟）
-      # - outbox poller 当前批次的事件分发
-      # 超过 300s 未退出将被 SIGKILL —— Temporal 端要等心跳超时才能把任务派给其他 worker
-
-      containers:
-      - name: worker
-        image: <registry>/<image>:<tag>
-        ports:
-        - name: health
-          containerPort: 8080
-
-        # ─── preStop Hook ───────────────────────────────────
-        lifecycle:
-          preStop:
-            exec:
-              command: ["sh", "-c", "sleep 5"]
-        # 让 readinessProbe 提前进入 503 + 给 outbox poller 当前批次缓冲
-
-        # ─── Readiness Probe ────────────────────────────────
-        # Worker 不挂 Service，readinessProbe 主要用来反映"是否健康"给运维面板
-        # 也作为部署阶段判断新 Pod 是否启动成功的依据
-        readinessProbe:
-          httpGet:
-            path: /health/ready
-            port: 8080
-          initialDelaySeconds: 5
-          periodSeconds: 5
-          failureThreshold: 3
-          successThreshold: 1
-
-        # ─── Liveness Probe ─────────────────────────────────
-        # 检测进程僵死（如事件循环被阻塞），失败后 K8s 重启容器
-        livenessProbe:
-          httpGet:
-            path: /health/live
-            port: 8080
-          initialDelaySeconds: 15
-          periodSeconds: 10
-          failureThreshold: 3
-
-        # ─── 资源与环境变量（按需） ─────────────────────────
-        env:
-        - name: TEMPORAL_ADDRESS
-          value: "<temporal-frontend>:7233"
-        - name: TEMPORAL_NAMESPACE
-          value: "default"
-        - name: TEMPORAL_TASK_QUEUE
-          value: "workflow-execution"
-        - name: DATABASE_URL
-          valueFrom:
-            secretKeyRef:
-              name: gadmin-db
-              key: url
-```
-
----
-
-## 4. 配置说明
-
-### 4.1 为什么 terminationGracePeriodSeconds = 300？
-
-| 因素 | 说明 |
-|------|------|
-| preStop sleep | 5s |
-| 当前 in-flight Activity / Workflow Task | 最长按业务实际定义，常见 30s–几分钟 |
-| 当前 in-flight outbox poll 批次 | 通常 < 5s（仅启动 Temporal workflow，不等执行） |
-| **总计余量** | 300s 覆盖大多数场景 |
-
-如果你的 Activity 可能执行超过 295s（300 − 5s preStop），有两条路：
-1. **加大 `terminationGracePeriodSeconds`**（例如长跑批量任务）；
-2. **让 Activity 支持心跳取消**：`Context.current().heartbeat()` + `Context.current().cancellationSignal`，shutdown 时 worker 会向 Activity 发送 cancellation，business code 可以选择中断并提前返回，让 Temporal 把任务重派给其他 worker。
-
-### 4.2 maxUnavailable 与 server 的差异
-
-server 用 `maxUnavailable: 0`，因为它直面用户流量、Pod 数变少会立刻反映为请求失败。Worker 不接流量，副本短暂少一个不影响 Temporal 的 task 派发（Temporal 自己有 polling 模型 + 流控），所以这里放宽到 `1` 减少升级耗时。如对延迟敏感（例如就只跑 1 副本），可以收紧到 `0`。
-
-### 4.3 Outbox poller 的语义边界
-
-⚠️ **当前实现有一个独立于 graceful 的语义问题**：`UPDATE ... SET processed = TRUE` 与 `temporalClient.workflow.start(...)` 不在同一事务里。如果在两者之间被 SIGKILL（或 stop() 等到 grace 超时），事件已被标记为 processed 但 workflow 实例没建立，下一次 poll 不会再处理它。
-
-graceful 关闭把这个窗口最小化（一定会等当前 poll 内的 `for (const row of rows)` 循环走完），但**没有彻底消除**。彻底解决需要把 `UPDATE` 与 `INSERT t_workflow_instance + workflow.start` 改造为：先 INSERT instance + 启 workflow，成功后再 mark outbox processed —— 这是另一个独立的修复。
-
----
-
-## 5. 验证方法
-
-### 5.1 本地验证 Shutdown
-
-```bash
-cd temporal/worker && yarn build && yarn start &
-WORKER_PID=$!
-
-# 等服务启动
-sleep 3
-
-# 验证 health
-curl -s http://localhost:8080/health/live   # {"status":"ok"}
-curl -s http://localhost:8080/health/ready  # {"status":"ok"}
-
-# 发送 SIGTERM
-kill -TERM $WORKER_PID
-
-# 期望日志依次出现：
-#   [Worker] SIGTERM received, beginning graceful shutdown...
-#   [Worker] worker.shutdown() called, draining in-flight tasks
-#   [OutboxPoller] Stopped, resources released
-#   [Worker] Health server closed
-#   [Worker] Temporal connection closed. Bye.
-# 进程以 exit code 0 退出
-```
-
-### 5.2 K8s 环境验证
-
-```bash
-# 观察滚动升级
-kubectl rollout status deployment/gadmin-workflow-worker -w
-
-# 看 Pod 事件确认 preStop 执行
-kubectl describe pod <pod-name> | grep -A5 "Events"
-
-# 升级期间持续触发事件，验证不丢任务
-# （根据业务，向能触发 outbox 的表持续写入，再去 t_workflow_instance 比对）
-```
-
----
-
-## 6. 信号传递链路
-
-```
-K8s kubelet
-    │
-    └─► containerd: 发送 STOPSIGNAL (SIGTERM)
-         │
-         └─► Node.js process（PID 1，因 CMD 是 exec form）
-              │
-              ├─► process.on('SIGTERM') handler
-              │    ├─► worker.shutdown()          → worker.run() 进入 draining 状态
-              │    ├─► outboxPoller.stop()        → 关 PG / Temporal client
-              │    └─► healthServer.close()
-              │
-              └─► await worker.run() resolve → await connection.close() → 进程退出
-```
-
----
-
-## 7. 故障场景与应对
-
-| 场景 | 现象 | 应对 |
-|------|------|------|
-| Activity 执行时间超过 grace period | 被 SIGKILL；Temporal 等心跳超时后重派 | 让 Activity 支持心跳 + cancellation；或加大 grace period |
-| outbox poll 中途被 SIGKILL | 已 mark processed 但未启 workflow 的事件丢失 | 见 §4.3，需独立修复事务边界 |
-| readinessProbe 失败 | 仅影响监控/调度面板；不影响 task 派发 | 检查日志、PG / Temporal 连接 |
-| livenessProbe 失败 | K8s 重启容器（同样走 SIGTERM → graceful path） | 排查事件循环阻塞（同步重 IO？deadlock？） |
-| `worker.shutdown()` 后迟迟不 resolve | 一定有 Activity 长时间不返回 | 最终 SIGKILL，Temporal 端等超时；治本看 §4.1 第 2 项 |