auto_control

248 Commits 2 Branches 6 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
butubb	da77d8eb6b	fix: 回归脚本 Windows 可用 + 加"禁止对生产库跑"安全闸；迁移脚本去掉 GBK 控制台会崩的符号 - scripts/regression_test.py: * signal.alarm 加 hasattr 守卫（Windows 上直接 AttributeError 退出， backlog A4）→ 本机终于能跑"一条命令扫全接口 500" * 新增安全闸：.env 声明 prod、或目标库 app_meta.deployment_env=prod 时拒绝运行（exit 3）。本脚本会发真实写请求（设备池增删/剪贴板注入/ 亮灭屏），跑在生产配置上就是拿正式数据做实验 - scripts/migrate_sqlite_to_mysql.py: stdout 重设为 UTF-8 并去掉 ✔/✘ 符号。实测在 GBK 控制台里打印 ✔ 会抛 UnicodeEncodeError，而且崩在"写库标签"之前，看起来像迁移失败（数据其实已搬完） - doc/backlog/TODO.md: A4 移入已完成；gitignore 条目更新（mcp_audit.log 已补， uiauto.pid 仍缺）；登记 MySQL 迁移与回归安全闸实测（对 192.168.2.27 的 auto_control_dev）：数据迁移 12 张表逐表 SHA-256 一致；应用直连 MySQL 全部接口 200，设备名/指纹唯一索引语义与 SQLite 一致（空值可重复、非空重复被拦、大小写敏感 A08≠a08）；备份导出→预览→应用往返正常。	2026-09-13 10:48:36 +08:00
butubb	429aaf6283	feat: SQLite → MySQL 数据迁移脚本 + 建库建账号 SQL（P3） - scripts/migrate_sqlite_to_mysql.py（新增）：源库完整性校验 → 列宽审计（SQLite 不强制长度，MySQL 严格模式下超长直接报错，先拦下）→ 建目标 schema（复用平台的 create_all + _sync_columns + 唯一索引）→ 逐表单事务搬行 → 逐表行数 + 全行 SHA-256 比对 → 写库环境标签与 schema_version。支持 --dry-run / --mode verify / --schema-only； --env prod 必须 --allow-prod（+ 交互确认或 --yes）；目标库已登记别的环境时拒绝 - scripts/sql/init_mysql_5.7.sql（新增）：建 auto_control / auto_control_dev 两个库（utf8mb4 + utf8mb4_bin）+ 专用账号与授权 - doc/DEPLOY.md §7.2：补 SQLite→MySQL 迁移流程与注意事项比对口径踩坑记录：验证哈希必须两边都从驱动层原生读。走 ORM/Core 的 typed select 会把 Boolean 读成 True/False，而源库 SQLite 原始读出来是 1/0 —— 三张带布尔列的表（user/device/task_job）会全部误报"不一致"。现在统一用原生 SQL 回读 + 值规范化（bool→int、整数值浮点→int、bytes→str）。自测（目标用 SQLite 代跑，MySQL 专属部分待 P4 真库验证）：12 张表逐表 SHA-256 一致、重复迁移幂等、verify 模式通过。	2026-09-13 10:37:15 +08:00

Author

SHA1

Message

Date

butubb

da77d8eb6b

fix: 回归脚本 Windows 可用 + 加"禁止对生产库跑"安全闸；迁移脚本去掉 GBK 控制台会崩的符号

- scripts/regression_test.py:
  * signal.alarm 加 hasattr 守卫（Windows 上直接 AttributeError 退出，
    backlog A4）→ 本机终于能跑"一条命令扫全接口 500"
  * 新增安全闸：.env 声明 prod、或目标库 app_meta.deployment_env=prod 时
    **拒绝运行**（exit 3）。本脚本会发真实写请求（设备池增删/剪贴板注入/
    亮灭屏），跑在生产配置上就是拿正式数据做实验
- scripts/migrate_sqlite_to_mysql.py: stdout 重设为 UTF-8 并去掉 ✔/✘ 符号。
  实测在 GBK 控制台里打印 ✔ 会抛 UnicodeEncodeError，而且崩在"写库标签"之前，
  看起来像迁移失败（数据其实已搬完）
- doc/backlog/TODO.md: A4 移入已完成；gitignore 条目更新（mcp_audit.log 已补，
  uiauto.pid 仍缺）；登记 MySQL 迁移与回归安全闸

实测（对 192.168.2.27 的 auto_control_dev）：数据迁移 12 张表逐表 SHA-256 一致；
应用直连 MySQL 全部接口 200，设备名/指纹唯一索引语义与 SQLite 一致（空值可重复、
非空重复被拦、大小写敏感 A08≠a08）；备份导出→预览→应用往返正常。

2026-09-13 10:48:36 +08:00

butubb

429aaf6283

feat: SQLite → MySQL 数据迁移脚本 + 建库建账号 SQL（P3）

- scripts/migrate_sqlite_to_mysql.py（新增）：源库完整性校验 → 列宽审计（SQLite 不强制
  长度，MySQL 严格模式下超长直接报错，先拦下）→ 建目标 schema（复用平台的 create_all
  + _sync_columns + 唯一索引）→ 逐表单事务搬行 → 逐表行数 + 全行 SHA-256 比对 →
  写库环境标签与 schema_version。支持 --dry-run / --mode verify / --schema-only；
  --env prod 必须 --allow-prod（+ 交互确认或 --yes）；目标库已登记别的环境时拒绝
- scripts/sql/init_mysql_5.7.sql（新增）：建 auto_control / auto_control_dev 两个库
  （utf8mb4 + utf8mb4_bin）+ 专用账号与授权
- doc/DEPLOY.md §7.2：补 SQLite→MySQL 迁移流程与注意事项

比对口径踩坑记录：验证哈希必须两边都从**驱动层原生读**。走 ORM/Core 的 typed
select 会把 Boolean 读成 True/False，而源库 SQLite 原始读出来是 1/0 —— 三张带
布尔列的表（user/device/task_job）会全部误报"不一致"。现在统一用原生 SQL 回读 +
值规范化（bool→int、整数值浮点→int、bytes→str）。

自测（目标用 SQLite 代跑，MySQL 专属部分待 P4 真库验证）：12 张表逐表 SHA-256 一致、
重复迁移幂等、verify 模式通过。

2026-09-13 10:37:15 +08:00