本技能聚焦长时运行的批量或同步任务：循环处理 N 个条目、中途可能失败，核心难点在于第 K 个条目失败时的报告、落盘与下一次运行行为。
用途与主要能力：设计并审查这类任务，避免静默少采、重复应用或为未完成工作计费。要点包括：
-
退出码是自动化唯一读取的信号。逐条错误只打警告、循环继续并最终返回 0，会让 cron、CI、监督进程一直认为任务健康。应统计失败条目并在状态中体现，失败时返回非零；部分成功需显式 opt-in（如 --allow-partial），不能默认静默。
-
检查点记录“实际发生了什么”。不要把“已尝试未完成”记为完成，否则后续条目永久待处理；批处理失败时应报告已成功单元数（如 PartialBatch(applied)），或让工作单元原子化，避免重试重复应用。
-
检查点文件须原子写入并固定权限。用同目录临时文件、flush、fsync 后 rename 覆盖，切勿把临时文件放 /tmp。注意 os.CreateTemp 默认 0600 会改变原文件权限；临时文件命名须让按 *.json 扫描的逻辑忽略；失败路径要清理临时文件。
-
逐条容错须在共享错误处理之前决定。共享 handle_api_error 常为致命默认，应在委派前对可容忍情况分支（如限流走重试策略、其余跳过并计数），并在汇总中报告 skipped。改变共享处理器契约时须 grep 其他调用方。输出应增量写出，避免最后一步失败丢失全部结果。
-
区分“零”与“取数失败”。用 is None 判断而非真值判断，失败保持未知并计入 incomplete，可加 clones_available 列、manifest 或非零退出码作为伴随信号。有汇总与明细时应交叉校验，正则须容忍真实 HTML 的换行与缩进，必要时按 data-date 等权威属性解析。
-
抓取 HTML 时加固请求：设置显式超时客户端、描述性 User-Agent 和 Accept-Language。
-
每次重试设上界并按工作单元计数，成功后重置。注意共享处理器若已等待，调用方不应再次 sleep。
-
增量游标：存储粒度上边界应重新包含，比较双方须统一到 UTC 再截断，避免本地时区导致边界日永久跳过；配合按日期合并的幂等步骤更安全。
限制：资料未提供具体安装命令、依赖版本或完整可运行示例。