butubb/auto_control
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
239 Commits 2 Branches 6 Tags
438710f830f197705f11a5c6174c87678db4b201
Commit Graph
29 Commits
Author SHA1 Message Date
butubb beb51637dd feat(设备): 电量显示（大屏 + 监控页）+ 低电量 webhook 告警 
需求：大屏和监控页都要能看到每台设备的电量，并且"低于多少电量就发通知"。

数据从哪来：`adb -s <serial> shell dumpsys battery`（**只读**，实测 0.2~0.35s/台，
11 台并发一轮 0.44s）。设备只要在 `adb devices` 里就说明 transport 现成，
**不需要 connect**——所以连空闲设备也能查。这是本模块敢每轮扫全量的前提，
也是这条只读路径与"空闲设备不主动 connect"红线（DEVELOPMENT.md §2 #3）的边界，
已写进文档免得后人误加 connect。

- core/device_battery.py（新）：后台 daemon 线程 `device-battery`（照 device_discovery
  的 init_app/shutdown 模式），默认 60s 一轮，采「设备池 ∩ 在线」（与 list_ready 同口径，
  adb 可见但不归平台管的设备不上屏也不告警）。
  · 结果**只放内存**（不落库 → 不建表、不动备份覆盖清单），离线设备保留最后读数；
  · 读失败不清缓存：list_devices 失败时若照清会把整份缓存抹掉、大屏全体变「—」；
  · 配置存 `app_meta.device_battery`（照 step_defaults：出厂值 + 白名单 + 范围钳制 +
    只落与出厂值不同的字段），改阈值不用重启（线程每轮重读配置）。
- 告警：事件 `device.battery.low` / `device.battery.recovered`（默认关，去通知页勾订阅）。
  **按档位做状态沿**（0 正常 / 1 低 / 2 严重）：掉档才报、严重再报一次、恢复报一次；
  迟滞 +5% 避免在阈值上下反复告警；同档位每 6h 重复提醒一次。
  "充电中"看的是 `status:` 行（2/5），**不是"插着电"**——所以"插着却没充电"
  （劣质线/温控/满电停充 status:4）仍会告警，那正是最该知道的情况（实测 fleet 里
  就有一台 8% 插着 AC 但 `Max charging current: 0`）。
- GET /api/status 每台设备多一个 `battery`：`{level,charging,at,tier}`。
  **tier 由后端算好**，前端只按它上色——阈值只在「工具 → 设备发现 → 电量监控」一处定义，
  免得 JS 里再判一遍、两边不一致。
- 前端：大屏卡片型号行右侧加电量徽标（绿/黄/红 + ⚡ 充电中，离线置灰），
  `cardHtml`/`renderGrid` 增量更新/脏检查白名单三处都改了（漏一处就不刷新）；
  监控页设备表新增可排序的「电量」列（空表 colspan 11 顺带对齐了）。
- 接口：GET/POST /api/devices/battery[/settings] + POST /scan（需设备权限，
  与 /api/devices/discovery/* 同权限档）。

自测：单元 30 项（解析真机输出/档位/状态机/钳制，含 scale=255、无 status 行、
垃圾输出等边界）、集成 27 项（临时库自建设备池：缓存/通知/离线保留/删设备清理/
配置往返/阈值改动即时生效）、真实 11 台设备一轮 0.44s 全读到、API 端到端
（登录/权限/钳制/越界/REST 往返/页面 DOM）、两份前端各自语法检查 + 渲染用例。
 2026-09-24 08:37:42 +08:00
butubb c29516cff5 feat(任务): 任务级「公共巡检」——独立于步骤画布的守护条件（含 webhook 通知） 
需求：任务编辑器里能单独配"这个任务每隔 N 秒检查一次"——熄屏就点亮、某个元素
出现就通知、掉出 App 就停本设备；通知标题正文要能自己写。

配置与执行分离（这是本次的关键设计）：
- **配置是任务级的**（`params.watchers`），在任务编辑器单独一块，不进步骤画布；
- **执行是穿插的**：worker 每执行完一步、以及长等待的每个分片，看一眼哪个巡检
  到点了。不起线程 → 不需要并发模型，也不会和主流程抢屏幕（两边同时点屏幕会
  互相打断）。代价是精度受步长影响（某步卡 30s，巡检最多晚 30s），已在文档写明。

- core/patrol.py（新）：检查项/动作注册表（CHECKS/ACTIONS）+ evaluate/act。
  检查：屏幕熄灭/亮着、元素存在/不存在、前台是/不是某 App；
  动作：只通知、点亮、息屏、停止本设备。屏幕走 `dumpsys power`（0.3s，
  不用 d.info——那玩意在部分设备要 14s），前台走 d.app_current()（0.7s）。
- tasks/generic/task.py：`_maybe_patrol` / `_run_patrol`（冷却、命中记一条
  步骤明细、发通知）；**文案在动作之前渲染**——点亮后 {screen} 就成了"亮屏"，
  用户要看的是"发现熄屏，已点亮"。
- 任务编辑器新增「公共巡检」块（static/admin/tasks.js）+ 样式；保存进 params.watchers。
- 通知：新增事件 `task.patrol.hit`（巡检命中）与 `task.notify.custom`（步骤发通知）；
  给了 title 就用它当标题（不再拼前缀），level 字段可点名级别。

顺带（巡检需要的原语，也可单独用）：
- if_el 条件判断支持 `selector_type=screen`（亮/熄）与 `foreground`（前台包名）；
  非元素条件不参与「选择器健康」统计（否则会攒出假的"选择器失效"告警）。
- 新增两个步骤：`notify`（发自定义通知）、`stop_self`（停本设备，记"被停止"
  而不是失败，不触发重试）。步骤类型 18 → 20，相关文档计数一并更新。

修 bug：`wait` 步骤在巡检耗时超过剩余时间后 `sleep(负数)` 抛
"sleep length must be non-negative"（真机联调抓到，已 clamp 到 0）。

自测：假设备单测 12 组（命中/冷却/间隔/元素/前台/停止/静默/异常不炸）；
真机联调：熄屏→点亮（False→True）+ 通知文案正确、掉出抖音按间隔命中 5 次、
长等待里穿插生效且步骤回到 ok、清理后用户通知配置原样恢复。
文档：TASK_DEV §4.5（含两个可抄的例子）与步骤表/条件类型、NOTIFY §3、README。
 2026-09-16 13:02:40 +08:00
butubb 16e3e162b2 fix(通知): 多设备批次不再逐台报成功；批次汇总瘦身并列出失败设备；设备只显示名字 
用户反馈：一条任务覆盖 13 台设备，每台成功都推一条，群里被刷屏；批次汇总里
「任务：抖音养号」与标题重复、「样本：抖音养号」毫无信息量、「stopped」还是英文。

- task_manager：
  · **多设备批次不发 `task.device.success`**（批次汇总里已有成功台数；单台任务照发）；
    失败仍逐台发——那是少数，且要知道是哪台；
  · `_BatchTracker` 收集失败设备（`名字（型号）：原因`，最多 5 条）并加进批次汇总；
  · 设备级事件带 `model`：型号取自**设备池快照**（批次开始时一次查好带下去），
    不是 worker 每次连接现采的（那次 `d.info()` 可能超时 → 空），也不查库；
- notifier：
  · 聚合窗口口径修正：事件声明 `agg_window=0`（批次结束/服务启停/备份恢复等低频
    高危事件）**不再被 hook 的窗口拖住**——原先事件级设置完全失效；
  · 「样本」行只在真的合并了多条(>1)时出现，且按**设备**维度写（合并多台时写
    任务名每条都一样）；与标题重复的字段行（「任务：x」）不再重复渲染；
  · 设备名与地址同时存在时**只显示名字**（IP 是给日志看的）；
  · 补 `stopped`/`failed_devices` 中文标签（原先直接显示英文 key）；
- notify_events：批次事件补 `skipped`/`failed_devices` 字段，设备事件补 `model`。

实测（dev 真机 + 假接收端）：
  批次 2 台 → 只收到 batch.started/finished，无 device.success，汇总 总数2/成功1/跳过1；
  单台任务 → 收到 device.success，显示「设备：cs1 / 型号：M2010J19SC」不含 IP。
文档：doc/NOTIFY.md §3（多设备批次怎么发 + 批次消息样例）、§6（窗口口径与注意事项）。
 2026-09-16 09:47:25 +08:00
butubb 621d48c800 feat(日志): 任务步骤明细表 + 「日志 → 步骤明细」面板（按设备/任务/时间过滤、按运行归组、导出 CSV） 
文本日志只能 grep，"这台设备这次运行为什么失败"翻起来很费劲。新增一张
**结构化**的步骤明细表，把"哪一步、什么类型、哪个选择器、结果、耗时"落库。

- core/models.py：新增 task_step_log（run_id/job/设备/step_path/selector/
  result/detail/duration_ms），索引 run_id、created_at、(serial,created_at)、
  (job_id,created_at)；
- core/step_log.py（新）：**专用写线程 + 有界队列**批量落库——步骤执行是热路径，
  任务线程只 put_nowait（实测 9000 次入队 31ms），队列满丢弃并计数，绝不阻塞；
  另有保留期清理（默认 14 天，每日 04:13 + 每次启动）；
- tasks/generic/task.py：_exec_one 记一条（异常=error / handler 返回 False=miss /
  未知类型=unknown / 概率未触发=skip）；_exec_steps 维护路径栈得到 "2.1.3"
  这样的嵌套位置；**单次运行封顶 2000 条**——forever 循环任务否则会写爆表；
- 运行上下文 ctx（run_id/job_id/job_name/device_name）由 TaskManager 生成，
  经 create_worker(serial, params, ctx=None) 传入 worker（扩展点向后兼容）；
- 接口：/api/step_logs（过滤+分页）、/runs（按运行归组）、/filters（下拉选项）、
  /download（CSV，带 BOM）；
- 前端：日志页拆成「文件日志 / 步骤明细」子分栏 + static/admin/steplog.js。

红线：新表自动进备份覆盖清单（SUMMARY_TABLES 由元数据派生），已补
TABLE_LABELS 中文标签，导出实测 14 张表、coverage_missing 为空。

文档：DATA_MODEL §2.8/§1、API §10.2、ARCHITECTURE §1.1/§2.2/§3.1、
DEVELOPMENT §5.2 与红线表、DEPLOY §5.2、TASK_DEV §8.3、README。
 2026-09-16 08:58:43 +08:00
butubb 97cec6e211 feat(通知): 系统级 Webhook 通知子系统（事件目录 + 可插拔适配器 + 防刷屏） 
平台此前出了问题只能靠人盯页面。现在各组件统一走 `notifier.notify(事件, **字段)`，
推到企业微信 / 自建服务；**所有可通知点都登记进事件目录，默认全关，用户按 webhook 勾选**。

## 架构（`core/notifier.py` + `core/notify_events.py`）
业务线程调 `notify()` → 只做内存操作（读配置快照/匹配订阅/入队）→ 返回；
后台 1 个 dispatcher（聚合 + 每 hook 限流 + 折叠摘要）+ 3 个 sender（真实 HTTP、退避重试）
负责真正发出去。硬约束：**notify 零 DB、零 HTTP、零阻塞、异常不冒泡**——所以任务线程里
可以直接调（不用 app_context、不用 try/except），但**必须放在所有 `with self._lock` 之外**。

- **事件目录 36 条**（任务批次/单设备/设备/Worker/业务/安装/系统/AI），支持 `task.*` 通配订阅；
  语义分工避免重复告警：`worker.*` 是单次尝试级，`task.device.success/failed` 是唯一权威结论。
- **适配器可插拔**：`wecom`（markdown，按 4096 **字节**截断、超限不截半个汉字）+
  `json`（模板占位符，替换值按 JSON 转义，保存前干跑校验）；钉钉/飞书留了插槽（前端置灰）。
- **防打爆四层**：聚合窗口（默认 30s，同批次合并成一条并带样本）→ 令牌桶限流（默认 18/分，
  对齐企微硬限 20）→ 被限流的**折叠成摘要不丢弃** → 有界队列背压。取舍：失败通知最多延迟
  一个窗口，换来群不被刷屏。

## 安全与存储
- 配置只落 `app_meta.notify_webhooks` 一个键（**不建表** → 不涉及备份覆盖红线）。
- URL 本身就是凭据（企微 `?key=`）→ 接口回显/发送记录/日志一律 `mask_url()/scrub()`；
  编辑时留空即不修改；secret 永不回显。DATA_MODEL 的明文凭据告警补上了这一条。
- 发送记录：内存环形缓冲 200 条（重启清空）+ 独立 `logs/notify.log`。

## 接入点（每个都放在锁外、不改 return 顺序）
task_manager（批次开始/结束用新增的 `_BatchTracker` 统一在 finally 计数、单设备成功/失败/
离线/重试/停止/抢占/归还/cron 停止）、device_worker 心跳看门狗、generic 任务选择器连续失效、
apk 安装开始/完成、设备上下线（**状态沿检测**，只报新变化）、备份导出/恢复、经验巡检、
用户登录、服务启停。

## 前端
系统 Tab 新增「通知 / Webhook」子分栏：多条 webhook 列表（URL 打码）+ 编辑弹窗（格式/URL/
密钥/事件勾选树带 ★建议/聚合/限流/自定义模板/预览）+ 发送测试 + 发送记录。

## 自测
- 进程内逻辑 10 组断言全绿：聚合合并、限流+折叠、无配置/全局关静默丢弃、未知事件、
  内部异常不外泄、JSON 转义（标题含引号换行仍合法）、URL/异常消息脱敏、配置校验。
- 端到端（假 webhook 接收端）17 项断言全绿：真实事件投递（user.login / task.batch.no_device）、
  企微请求体形状、**HTTP 200 + errcode 93000 判为失败**、500 重试 3 次、记录里 URL 打码。
- 韧性：webhook 指向黑洞地址时登录耗时 100~114ms（基线 107~133ms，**异步隔离生效**）；
  配置写成坏 JSON 服务照常启动、通知静默不发、日志有 error（服务端实测后已复原）。
- 页面：系统 → 通知 面板/弹窗/36 个事件复选框/预览全部正常，无 JS 报错。
- 自测数据已清理（webhook、自建任务、写坏又复原的配置键）。

文档：新增 doc/NOTIFY.md（事件表/配置/格式约束/防刷屏/加事件三步骤/排障）并登记进 doc/README；
API.md §2.11；DATA_MODEL 的 app_meta 键表与明文凭据告警；ARCHITECTURE 线程表/分层/扩展点；
根 README 功能索引与日志表。
 2026-09-15 13:55:14 +08:00
butubb 64fadde568 fix: 断联设备表「换地址」按钮传参丢失（缺 data-serial）+ 删除任务/分组兼容内存不一致 
- tools.js：断联设备表的「换地址」按钮漏了 data-serial 属性，onclick 里
  this.dataset.serial 是 undefined → 接口报「缺少 old_serial 或 new_serial」。
  设备池表里的同名按钮是传字面量的，所以只有断联表这条路径坏。
  顺带给 relocatePoolDev 加参数防呆（取不到地址时给明确提示，不静默）
- task_manager.delete_job / delete_group：原先只在"内存里有"时才删库行，
  内存与库不一致时（手工插行、上次异常退出、旧版本漏删）会出现"删不掉的
  任务/分组"（API 404 但库行还在、重启复活）。改为无论内存有没有都尝试删库行

自测：浏览器验证断联表两个按钮都带 data-serial；relocate 接口端到端（上一轮已验）；
删除接口在前端删除分组/任务后 DB 与内存一致
 2026-09-11 11:23:19 +08:00
butubb 0a1b4d6122 feat: 设备身份改为「名称 + 指纹」——更换 IP 自动认领，分组/任务引用自动同步 
背景：设备池原先拿 serial（IP）当身份。设备一换 IP（DHCP 重新分配）旧记录就成了连不上的
僵尸条目（表现为"断联·自动重连中"但设备并没关机），分组与 serial 模式的任务还吊着死地址。
2026-09-11 实际发生：.70 变成 .71、.72 消失，平台两个条目永远连不上。

实现
- **设备名称必填且唯一**：加入设备必须填名称；库层面用部分唯一索引兜底
  （ux_device_name / ux_device_fingerprint，WHERE 非空 → 兼容历史空值），管理页可改名
- **设备指纹**（ro.serialno）：网络设备添加/确认/扫描/采集型号时自动读取；
  身份三层拆分——名称（人可读，稳定）、指纹（机器识别，稳定）、serial（当前地址，可变）
- **自动认领**：添加或确认设备时指纹命中池中已有记录 → 迁移原记录到新地址
  （名称/型号/备注/启用状态/添加时间全保留），不新增条目
- **人工认领** `POST /api/devices/pool/relocate`：旧地址已断联、指纹没采过时的兜底——
  人工指认"这条就是那台，现在在 X"，迁移并同步引用
- **引用同步**：认领/迁址时把 device_group.serials 与 task_job.target.serial 的旧地址
  换成新地址。⚠️ 必须同时改**内存**：分组/任务在 TaskManager 里另有内存副本且调度用内存对象，
  只改库不重启不生效 → device_pool 迁址后回调 TaskManager.sync_device_serial
  （装配层用 set_move_hook 注册；device_pool 不能反向 import task_manager，会循环依赖）
- **前端**：待连接池新增「识别」列（指纹命中时提示"≈ 名称（原 IP）"，按钮变「认领为 X」）；
  设备池新增「名称/指纹」列与「改名/换地址」操作；断联设备表也加「换地址」（用户看到断联就在这里）
- 添加设备接口改用 adb_connect_light（单次短超时），避免不可达 IP 让请求卡 30s+；重名校验提前到 adb 之前

文档：API.md §6 重写（设备身份/认领/新接口）、DATA_MODEL.md（新列 + v5/v6 迁移 + 唯一索引）、
ARCHITECTURE.md §4.0（身份三层与引用同步的内存坑）、DEPLOY.md 排查表加"断联但没关机"条目

自测（全通过）：名称必填/唯一/改名/重名拒绝（含库层面约束）；指纹采集（真实读到 .71 的
gy7lskwkkvj7c6b6）；自动认领（指纹命中→迁址+保留名称+带指纹+未命中不误判）；人工认领
（迁址+名称保留+分组与任务引用同步）；浏览器验证设备池/断联表/待连接池三个界面
 2026-09-11 11:03:38 +08:00
butubb f4b5316436 chore: 去掉 generic_steps 的默认步骤 + 重试失败带上真实原因 
- tasks/generic/task.py：DEFAULT_PARAMS 只留 max_duration，**不再内置示例步骤**
  （步骤只能由前端编辑器产出；此前默认的"打开抖音→循环看视频"只有后端在用，
  编辑器新建任务本来就是空的，等于埋了个和界面不一致的隐性默认值）
- 空步骤不再静默空跑：worker 立即抛错「通用步骤任务没有可执行步骤…」，
  设备表「最近错误」能看到（此前会走完 0 步当成功）
- core/task_manager.py：重试耗尽的 last_error 现在带上最后一次的真实失败原因，
  不再只有"重试N次失败"（用户看不到为什么失败）；max_attempts=1 显示"执行失败"
  而非费解的"重试1次失败"；长度截断 200 字符
- 文档：TASK_DEV §2.10 说明无默认步骤 + 空步骤会报错；API.md 的 task_types 示例
  改 default_params={"max_duration":0}，POST /api/jobs 补「steps 要一起传」提示

自测（全通过）：default_params 无 steps；无步骤任务真跑一次 → 设备错误信息完整含原因；
有步骤任务（wait 1s）真跑一次 → status=done 无错误；临时任务验完已删，任务集合复原
 2026-09-10 21:50:18 +08:00
butubb 98cdc39224 chore: 删除抖音养号任务类型，平台只保留 generic_steps 
tasks/douyin/（task_type=douyin_nurture）整体删除，唯一任务类型是 generic_steps。
所有默认值/文档/接口示例同步改成 generic_steps：

- tasks/：删 douyin 包；__init__ 只注册 generic；base.py/generic 注释改为照 generic 抄
- 默认值：core/models.py（列默认 + 旧 JSON 迁移默认）、core/task_manager.py TaskJob、
  web/tasks_api.py 建任务默认、static/admin/tasks.js 新建任务默认
- core/task_manager.py：去掉 douyin 专属的"清理废弃 comment 参数"迁移块，改为**启动时告警**
  仍残留已删类型的任务（只告警不改数据）；run_job_now 对已删类型直接返回明确错误，
  不再"报已触发、线程里静默失败"
- 清理残留：douyin_running 状态位（无任何读取方）、core/__init__、core/actions/*、
  core/logger.py 注释里的抖音示例
- 文档：README（特性/目录树/类型表/参数表/示例）、TASK_DEV（目录树/注册说明/模板引用）、
  ARCHITECTURE（注册示例/action 注册表示例）、API.md（task_types 与任务 JSON 示例）、
  AI_TASK_GEN（P1 去掉 douyin 预设）、DEVELOPMENT
- 注：示例里"抖音"作为**App 名**（MCP 列应用、AI 建任务的需求举例）保留，与任务类型无关

自测（全部通过）：类型列表只剩 generic_steps；建任务不传类型默认 generic_steps；传
douyin_nurture 被 400 拒；库里塞残留旧类型任务 → 启动日志告警 + 执行返回明确错误 +
不自动删用户数据；前端新建任务下拉 1 项且默认选中、界面建任务成功；监控页卡片两个按钮 +
覆盖设备正常。临时任务/数据验完已清理，任务集合复原。
 2026-09-10 21:43:08 +08:00
butubb 1a74372ad9 fix: 任务调度限定设备池——preempt 抢占模式的 all 目标原用 list_online()（含待连接/未入池设备，自动发现验证连上的设备会被任务误跑）；改为设备池内在线设备；group 模式同样过滤未入池设备（serial 模式保留显式指定） 2026-09-01 09:07:12 +08:00
butubb 4efe17c1c9 feat: 设备自动发现——定时扫描局域网+Tailscale 网段开放 adb 5555 的设备进入待连接池，用户确认后才加入正式设备池（不自动连接）；socket 并发探测+adb 短超时验证（state=device 过滤 unauthorized），配置存 app_meta 可前端调整；配套：adb_connect_light 验证短超时、DISABLE_SCHEDULER 回归开关 2026-08-30 10:57:07 +08:00
butubb 27530ff5ac fix: 手动执行不再受运行窗口限制（窗口只约束定时触发）——立即执行按钮在窗口外也可触发任务 2026-08-20 08:36:29 +08:00
butubb a9720e8b81 fix: 抢占归还丢失——preempted_job 在重试循环内被重置为 None，关键字任务一旦重试（attempt≥2）被抢占的养号任务永不恢复；提升到循环外+已有值不覆盖+归还时被抢占任务停用/删除也打日志 2026-08-19 15:46:18 +08:00
butubb 6f6093842c feat: 设备型号采集展示（devices 表 model 列+getprop 采集+管理页型号列/采集按钮+监控页兜底）+ fix: 监控页设备列错位（离线标签残留 td）、appver 端点误删恢复、appver 只查在线设备用轻量连接防挂起 2026-08-19 13:53:27 +08:00
butubb a5ce57b6fd 阶段3: 摘除 STF——删除 stf_client/stf_device_mgmt 与全部引用（STF 容器重启/设备管理/强制释放占用/agent 按钮/占用列），调度与设备管理完全基于本地设备池+adb；错误类迁入 device_worker，create_worker 去 stf 参数 2026-08-18 08:08:32 +08:00
butubb 645938b305 阶段2: USB 远程 adb server 打通（220 host 网络 5037 全接口监听，无需改 220）+ 自建远程看屏（MJPEG 流 + u2 触控 tap/swipe/key/text，ws-scrcpy 不在 npm 改自建） 2026-08-17 16:50:12 +08:00
butubb 5354fe6379 阶段1: 调度/生命周期切换 device_pool——task_manager 设备解析与状态查询、STFDevice 去 occupy/release、web_server 端点换数据源（USB 桥接保留到阶段 2） 2026-08-17 11:16:13 +08:00
butubb e48eeef49b feat: 任务抢占+归还（抢占任务结束后自动重启被抢占任务）+ 修复抢占死锁（stop_device 移出锁块）+ wait 步骤可中断 + 循环块新增一直循环模式（配合定时启动+停止实现全天候养号） 2026-08-16 08:12:05 +08:00
butubb 17f849f723 feat: STF设备管理彻底删除（脚本+断开+STF API清记录）+ 一键重连（后台跑connect脚本）+ 跳过原因日志区分离线/未就绪 + SSH超时错误分类 2026-08-15 15:22:55 +08:00
butubb 21d3aa8268 feat: 任务离线设备自动跳过（serial/分组模式触发时过滤 STF 池离线设备，默认开启，任务编辑器可勾选关闭） 2026-08-14 09:16:54 +08:00
butubb 5ccf622942 fix: 删除任务/分组持久化（重启不再复活）+ feat: APK 安装支持本机 USB 设备 2026-08-11 08:27:33 +08:00
butubb 794f40a880 feat: 调度简单设置（频率选择器）+ 运行窗口 + 下次运行列 2026-08-11 08:27:33 +08:00
butubb 5f914c4fe4 fix: 已删除设备残留失败记录不再出现在异常汇总 
- _merge_status 清理不在 STF 设备池且无运行 worker 的陈旧状态
- /api/summary 按当前设备池过滤，STF 异常时不隐藏任何记录
 2026-08-09 08:04:57 +08:00
butubb 0c4f586ae5 feat: 选择器健康检测 - 连续未命中自动上报，暴露"静默空转" 
通用任务 click 步骤连续 10 次找不到元素时判定选择器可能失效（App 改版），
记录 last_warning 并日志 ERROR，监控页设备行显示 ⚠ 警告。
解决"选择器失效但任务仍显示成功"的静默空转问题。
 2026-08-08 21:35:21 +08:00
butubb 6d3cc10bca feat: 任务批量触发错峰启动，分摊 adb 锁/STF occupy 风暴 
大量设备（如 100 台）同时触发时，按 0.2s/台间隔逐个启动 worker，
避免 adb connect 全局锁串行堆积和 STF occupy 并发风暴。
100 台 × 0.2s = 20s 全部开始启动，连接压力分摊。
 2026-08-08 21:09:03 +08:00
butubb fcbdb0a8a1 feat: 通用步骤支持概率触发、循环按时间、预计结束时间上报 
- 步骤新增 probability 参数：<100 时按百分比概率决定是否执行（实现"偶尔点赞"）
- loop 支持 loop_mode=rounds/time，按时间循环跑满 loop_duration 秒
- BaseWorker._start_timer 上报 end_time（开始+max_duration），task_manager 透出
 2026-08-08 16:30:54 +08:00
butubb 468e86f0a9 feat: 新增通用步骤任务+元素抓取，完善全部项目文档 
- 新增 generic_steps 通用步骤任务（可视化步骤编辑器编排流程，支持 open_app/click/swipe/input_text/wait/loop/group）

- 新增 core/uiauto_helper.py 封装 uiautodev 元素抓取客户端

- web_server 新增元素抓取/截图/设备列表等 API

- monitor.html 新增步骤编辑器、元素抓取模态框、独立关闭逻辑

- 新增 README.md 项目总览（快速上手/架构/配置/FAQ）

- 新增 doc/ARCHITECTURE.md 架构详解、doc/DEPLOY.md 部署指南、doc/API.md 接口文档

- 修复 doc/TASK_DEV.md：移除已删除的 comment 引用，补充 generic 包，更新注册示例

- .gitignore 忽略 .claude/ 工具产物
 2026-08-08 10:40:06 +08:00
butubb 186bded9d9 fix: 消除所有会导致STF断开连接的操作 - adb_connect移除kill-server硬重置(会断全网设备) - APK安装后不再adb_disconnect(IP:5555会断STF provider) - 扫描空闲设备不再adb connect/disconnect(直接标记空闲) 2026-08-07 15:43:17 +08:00
butubb bce48fc137 chore: 初始化仓库（排除 adb 二进制文件以解决推送超时） 2026-08-07 13:55:48 +08:00