批次驱动、三执行体、枢纽模型的 Windows 游戏资源归档流水线。
把「资源页 → 网盘转存 → 下载 → 解压 → 校验 → 删源包 → 投递到目标盘」这条重复的人工链条， 拆成可重跑、可中断、每一步都有显式状态的作业。
状态：阶段 0 —— 地基 lib 与 Windows 检测脚本已写完，第 1 次 Windows 实测已回来（SPEC §11.3），等第 2 次（装好 7-Zip 与系统 pwsh 之后）；批次、解压、投递等业务流程尚未落地。 详尽设计规格见
SPEC.md。 目标平台：Windows（本仓库在 macOS 上撰写，只存文档与规则，不存游戏数据）。
现状是每次都要手动重复一遍的流程：从资源站拿到页面 → 页面给出多个网盘链接 → 逐个转存 → 本地建游戏名文件夹 → 下载 → 解压 → 如需要用 MTool 加载翻译。而且实际工作对象从来不是一个游戏，是一组。
麻烦集中在解压这一段：压缩包通常有密码、有多重嵌套、有时要改文件名后缀才能正确解开。
你（约 3 分钟） 建批次：给一组链接 + 提取码 + 解压密码 + 目标路径
你（约 2 分钟） 在网盘客户端里转存 + 排进下载队列（下载目录只设一次）
↓
A · 巡检（自动） 每 10 分钟一轮：判下载完成 → 认领归位 → 只读预检 → 写状态
B · 作业（自动） 密码链 → 解压 → 递归解包 → 逐条目校验 → Defender → 删源包
B · 投递（自动） 把只剩游戏本体的目录整体移到 <目标盘>\<分组>\<游戏名>\
↓
你（30 秒） 全批跑完后看一次对账报告
中途不需要你介入，也不占用前台桌面。第一阶段（下载→解压→投递）完全用不到 Computer Use。
| 执行体 | 触发 | 无人值守 | 用 Computer Use | 干什么 |
|---|---|---|---|---|
| A · 巡检 | 计划任务（Interactive / Limited） | 是 | 否 | 下载完成判定、认领归位、只读预检、写状态、出报告 |
| B · 作业 | 计划任务（Interactive / Highest）或手动 | 是 | 否 | 解压、校验、Defender、删源包、投递 |
| C · 前台 | 人显式触发，短会话 | 否 | 是 | 只剩 MTool 翻译；网盘下载与资源页解析都是可选 |
为什么阶段一要切成 A/B 两半：B 需要 DPAPI 密码库和提权（MpCmdRun），A 不需要。
两者都能挂计划任务（同一用户的 Interactive 登录类型，DPAPI 可解），B 另加 -RunLevel Highest。
下载、解压、校验、删源包全部在一个固定的枢纽卷上完成，最后一步才把成品移到目标路径：
D:\GameFlow\ 脚本、规则、skills（进 Git）
D:\GameHub\ 枢纽：_inbox\ _stg\ games\ _trash\ batches\ _reports\
↓ 投递（同卷 = rename，跨卷 = 复制+删源）
E:\wen\games\hgames\202609\<游戏名>\ 每批指定，可在任意盘，也可留空之后再定
这么做换来四件事：同卷恒成立（认领归位与落地永远是 O(1) rename）、Defender 排除项只有一条、 解压期 MAX_PATH 预算是固定值、目标目录只接收成品且永不进删除白名单。 代价是跨卷投递要整体复制一次，时间与游戏体积成正比。
确定性优先。不猜。
- 密码不猜 —— 你给的密码先试，失败才去密码库按命中次数排序试，最多 8 次 7z 探测，用尽就停下报告。字典爆破、从游戏名推导、从 README 里「读懂」一段话，全部硬性禁止。
- 类型不猜 —— 7-Zip 本来就按内容嗅探，不传具体
-t类型名（传了反而会把能自动处理的情况变成硬失败）。 - 规则不猜 —— 重建分卷序列这类动作必须由批次条目显式声明。
- 不自适应、不加权评分。所有分支要么由显式规则决定，要么停下来落一个具名状态等人。唯一的例外是密码候选的尝试顺序可按命中次数排（只改先后，不改试哪些、试几次）。
删除是本项目风险最高的操作，由两条逐次执行的机器断言守住：
- D1–D12 十二条与条件（正确性判据，含逐条目 size 对账、卷集连续性、嵌套容器嗅探）
- I6 路径围栏 —— 删除目标必须在枢纽根之内，规范化全路径前缀比对，不跟随 reparse point。目标目录永不在删除白名单里
不设人工确认闸门：一次覆盖整批的确认既验证不了 D1–D12，也发现不了路径算错，还会被疲劳性地点掉。
引擎层吝啬，呈现层不吝啬。 对账报告要真正好读。
gameflow/
README.md ← 你在这里
SPEC.md ← 详尽设计规格（§1–§12，43 条决策台账）
PLAN.md ← 实施计划：先做什么、怎么算做完
docs/
WINDOWS-CHECK.md ← **在 Windows 上怎么测**：一条命令，九项检测（第九项可选）
scripts/lib/ 六个地基模块（104 条用例在 macOS + pwsh 7.6 上全绿；Windows 上 Journal/Lock/Paths 已在 5.1 与 pwsh 下全过，SevenZip 的 7z 集成部分**待装好 7-Zip 后验证**）
tests/ 零依赖测试 harness + lint + fixture
SPEC.md 讲「是什么、为什么」，PLAN.md 讲「先做什么、怎么算做完」。 准备动手就读 PLAN。
| 节 | 内容 | 什么时候看 |
|---|---|---|
| §1 | 概述、核心设计判断、非目标、合规边界 | 想知道「为什么这么设计」 |
| §1.7 | 端到端范例：一个典型批次 | 先读这节——我要给什么、我要做什么、我能拿到什么 |
| §2 | 三执行体、目录布局、MAX_PATH 预算、§2.9 枢纽与投递 | 想知道「东西放哪」 |
| §3 | 数据模型：批次 / 事件 / 状态 / 清单 / 规则 / 密码库 | 要动手实现时先读这节 |
| §4 | 状态机、迁移表、停机态手册 | 卡住了不知道该做什么 |
| §5 | 执行体 A：下载完成判定、归档识别、卷集归组、只读预检 | |
| §6 | 执行体 B：密码链、解压递归、逐条目校验、12 条删除判据 | 全篇技术密度最高、风险最高 |
| §7 | 执行体 C：会话模型、网盘适配、MTool、人工接力点 | |
| §8 | Codex 操作面（6 个 skills）与 PowerShell 工程约定 | |
| §9 | 安全、隐私与诚实局限、前置条件与 Preflight | 想知道「做不到什么」 |
| §10 | 落地路线 M0–M5、测试策略、验收 | 准备开工 |
| §11 | 待 Windows 实测清单（29 条）与实测记录（11.3） | 开工前第一件事 |
| §12 | 决策台账（含被否决的替代方案） | 想推翻某个决策之前 |
M0 = 在 Windows 上跑一次检测。 完整说明见 docs/WINDOWS-CHECK.md。
推荐交给 Windows 上的 Codex 执行——文档第一部分有一段可以直接发给它的指令，外加四个准备步骤（约 3 分钟）。 那条路径本身就是这次要测的：Codex 调 Windows PowerShell 5.1。
也可以自己在终端跑：
git clone https://github.com/mmy420/gameflow.git D:\GameFlow
cd D:\GameFlow
powershell -NoProfile -ExecutionPolicy Bypass -File .\tests\windows\Invoke-WindowsCheck.ps1 `
-HubRoot D:\GameHub -SampleGameDirs 'D:\Games\游戏A|E:\old\游戏B'多个游戏目录用 | 隔开、整串一对单引号——不能写成 'A','B'，经 -File 传进去会被拆坏。
这不是仪式感。本项目在 macOS 上开发，凡是 Windows 特有的行为都只能靠官方文档推断，
标了 【待测】 的地方不实测就写不出正确的实现。检测要回答的问题按分量排：
- 环境快照 —— 装的是 7-Zip CLI 还是只有 WinRAR/Bandizip GUI、系统 ANSI 代码页、文件系统类型。阶段 1 直接等它
- lib 在 5.1 下的真实行为 —— 104 条用例只在 macOS + pwsh 7.6 上绿过
- 跨进程互斥 —— 不成立的话 A 与 B 会同时动同一个游戏，阻塞性
- 真实游戏包的最长内部条目路径 —— 决定目录名降级会不会频繁触发
- Codex 沙盒能否写
D:\GameHub、会不会对脚本内部的子进程逐个审批 —— 只影响「对 Codex 说一句话手动触发」这条路径。 无人值守路径走 Windows 任务计划，不经过 Codex，不受影响（D-10、D-38）
之后按 A（只读）→ B（先关掉删除）→ B（打开删除）→ 投递 → C 的顺序推进，逐阶段任务与完成判据见 PLAN.md。
需求来自 Codex 会话「规划 Windows 游戏资源工作流」（01a08eba-1b68-7b33-9a7e-242a5be1c22a，2026-09-10），
该会话确立了批次驱动与两阶段拆分的方向。
在此基础上做了六条技术线的事实核查与一轮对抗式事实仲裁，推翻了原方案中的若干断言——影响最大的三条： Codex 内置浏览器没有按任务指定下载目录的能力、「改后缀」在绝大多数情况下根本不需要、 游戏目录名的真实约束不是「非 ASCII」而是「必须能在系统 ANSI 代码页内无损表示」。
后续几轮又推翻了两条自己的断言：「B 必须有人在场」（那只在 S4U 登录类型下成立）、
「密码候选按命中排序会违反不自适应原则」（它不改变结果，只改变到达结果的路径）。
详见 §1.6 的对照表与 §12 决策台账。