用途
该技能用于诊断 Windows 上 deepseek-harness（DSH）沙箱出现的意外访问拒绝：工作区写入或目录列表失败，或一个通常可读的路径无法读取。对于预期之内的拒绝情形（例如在工作区之外写入、只读模式下的任何写入、管道派生孙进程的 EPERM、ConstrainedLanguage 错误）则应向用户解释原因，而非用本技能修复。若审批被拒绝或不可用，应报告该路径为未诊断并停止。
主要能力
脚本没有模式开关，一条命令同时完成诊断与修复。参数 -Path、-AllowRoot 和 -Out 配合工作：
- 读取目标路径及其每一级上级目录，对链上缺少有效 WRITE_DAC 或 WRITE_OWNER 的目录，为当前登录用户添加完全控制允许项，因为缺少这些权限时 DSH 无法配置其工作区授权。
- 在其来源处移除显式的 AppContainer 软件包允许项（S-1-15-2-*，以 1 或 2 结尾的已知组除外），祖先目录优先，同时也会移除这些软件包的访问。
- 对沙箱无法配置的目录（沙箱在配置工作区根目录时报错所指示的状态）或授权根目录本身，在同一次运行中搜索其子树中的上述权限项，深层条目无需二次请求。这种有界遍历会报告被截断和不可读的目录；若被截断，可对仍然失败的更深路径再运行一次。
- 每项修改先备份，再通过重新读取验证。-AllowRoot 限定所有修改的范围：只有该目录本身或严格位于其中时才被修改，因此工作区根目录可以自行修复。
使用方式
安装命令：资料未提供。
调用示例（需替换为带引号的完整路径）：
& '<skill-directory>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<failing-path>' -AllowRoot '<authorized-directory>' -Out '<recovery-directory>' exit $LASTEXITCODE
-Out 应保持持久并由用户所有，最好放在失败工作区旁边；不要使用技能资源目录，因为技能卸载时该目录会被删除。每次调用只传一个路径。
脚本会写入权限，而受限令牌无法完成写权限操作，因此应在非受限环境下经批准运行该命令；在受限环境运行只会把沙箱自身的限制误报为缺少权限，永远没有意义。非受限运行不会提升 Windows 令牌权限。
不要拆分成先诊断后修复的两次调用，不要为同一修复请求两次审批，也不要传入不存在的模式开关。
读取输出
每条记录都会输出到 stdout、-Out 下的 acl-report-*.jsonl 文件，以及最终的 RECAP 行（含判定、修改、验证、拒绝和扫描信息）。由于工具输出只保留尾部，应优先读 RECAP，不够时再从报告中读具体记录。应信任验证记录，而不是“已完成”的声明。依据 details.nextAction 决策：
- verify_original_confined_operation：修复已验证，在受限环境中重复原始操作。
- stop：无修复发生，或拒绝终止了运行，报告后停止。
- restore_pending_then_stop：回滚未验证，按顺序执行打印出的恢复命令后停止。
拒绝项存在本身不证明因果关系，脚本从不删除拒绝项；DSH 的 S-1-4-* 授权和 Everyone 的 DeleteSubdirectoriesAndFiles 拒绝属于预期情况，不是冲突。阻碍修复的拒绝项会导致运行在尝试后恢复所作修改并结束（REPAIR_REFUSED 或 GRANT_FAILED）。每项修改在 -Out 中留下两个文件（acl-backup-<id>.json 及其 .ps1），运行会打印对应的 ROLLBACK 命令。
修复之后与停止之后
修复后，在受限环境中重复原始失败操作。已验证的修复不会因原始操作因其他原因再次失败而被撤销：应从新观察继续；若更深路径仍被拒绝，在同一路径上再运行同一条命令，同样一次调用、一次审批。
任何修复失败、被拒绝或验证失败后应停止。脚本已恢复该次调用的修改；不要重复运行或开始新的修复，也绝不手工删除拒绝项。
停止的运行仍需要给用户一个决定：指明阻塞对象及其缺失的权限或权限项、改动了什么、回滚了什么、恢复命令的顺序和报告路径。只有用户能解除沙箱限制，因此应请用户将会话临时切换到完全权限（full access），并说明这带来的可能：可在其中继续工作，或让助手继续基于报告排查此文件权限问题。随后请用户将会话作为反馈发送，并引用相关报告记录。示例措辞：
这个工作区被 Windows 文件权限挡住了：<对象> 上 <缺哪个权限 / 哪条权限项>。你可以把本会话切到「完全权限」(full access) 临时继续工作；切完之后既能直接干活，也可以让我继续排查这个文件权限问题（报告里已经有机制和证据）。也麻烦把这个会话作为反馈发出去，好让我们补上这个场景。
限制与禁止事项
- 不得手工编辑 ACL、更改所有者、删除拒绝项或递归替换子项权限。
- 不得以提权方式、通过 UAC 或 runas 运行脚本。
- 不得扩大 -AllowRoot 以触及更上层目录，不得重复已被拒绝或失败的调用。
- 审批请求须用用户语言、平实措辞一次性提出，说明脚本触碰的文件夹、将补充当前用户完全控制项并移除外来软件包权限项、文件内容和所有者不变、打印的恢复命令可撤销每项更改；请求中不要出现错误码、WRITE_DAC/WRITE_OWNER、S-1-15-2-* SID、icacls、ACL、ACE 等术语，应写“Windows 文件权限”而非 ACL 或 ACE。
- 报告应使用用户语言，说明分析的路径、修改、验证、恢复命令和下一步；获授权的非受限运行应如实标注，而非称为沙箱修复。
适用场景
适用于 Windows 上 DSH 沙箱工作区写入失败、目录列表失败，或通常可读路径无法读取的排查与修复；也适用于需要向用户解释预期内拒绝原因的情形。不适用于与沙箱 ACL 无关的普通 Windows 权限问题，资料未说明其在非 DSH 环境中的行为。