docs(windows): record the single-run ACL repair in the agent note

The note still described a diagnosis-then-repair workflow with a mode choice.
Record what shipped: one invocation for both repairs, the bounded subtree walk
under a directory the caller cannot provision, the authorized root repairing and
restoring itself, and the per-object recovery record plus script.

.agents/notes/implemented/feature/2026-08-08-windows-acl-restricted-token-sandbox.i18n.yaml

@@ -12,8 +12,8 @@
   en: 125dea7427047966
   zh: 1e459b1106597695
 /agent-note-windows-sandbox-rung-raw-acl-restricted-tokens-over-mxc-and-appcontainer/acl-diagnosis-and-recovery:
-  en: 8ea2f91a914d540b
-  zh: cafada631044e43a
+  en: 9ba5676ed8dd6367
+  zh: 9a8670e5bece9a14
 /agent-note-windows-sandbox-rung-raw-acl-restricted-tokens-over-mxc-and-appcontainer/how-the-restriction-works-why-no-new-identity:
   en: ac9b3d800889ea39
   zh: 9db1065b6027f65f

.agents/notes/implemented/feature/2026-08-08-windows-acl-restricted-token-sandbox.md

@@ -16,7 +16,7 @@ Implement the rung directly on the raw ACL mechanism: duplicate the caller's tok
 
 The bundled diagnosis skill runs its preserving ACL repairs outside the confined token because that token cannot inspect the conflicting objects. External PowerShell requires physical script files, so registration extracts resources from ASAR or SEA instead of exposing archive paths. The fiber owns that temporary copy. Recovery files live in the caller's persistent output directory so disposal of the skill does not remove the means to restore a DACL.
 
-A repair backs up before mutation and verifies effective access or the resulting ACEs. Failed invocations restore attempted changes in reverse order and remain failures: continuing after a failed grant would remove access without establishing the prerequisite. Inherited package entries are repaired at their explicit sources, preserving inheritance; incomplete or out-of-scope sources prevent mutation. Labels and denies remain untouched because removing them could defeat the backend's confinement or an intentional user policy.
+A repair backs up before mutation and verifies effective access or the resulting ACEs. One invocation performs every repair it can prove, so a single sandbox failure needs one approval instead of a diagnosis followed by a repair: it adds the caller's full-control ACE to the chain directories that lack effective `WRITE_DAC` or `WRITE_OWNER`, and removes explicit package allow ACEs at their sources. The authorized root itself may be modified and restored, so a workspace root can repair and roll itself back, and recovery artifacts are one DACL record plus one copy of the restoring script per modified object. When the requested directory is one the caller cannot provision — the object a provisioning error names — that same invocation also examines its subtree for explicit package allow ACEs through a bounded walk that reports truncation, because the conflicting entry often sits below the reported root. Failed invocations restore attempted changes in reverse order and remain failures: continuing after a failed change would remove access without establishing the prerequisite. Inherited package entries are repaired at their explicit sources, preserving inheritance; incomplete or out-of-scope sources prevent mutation. Labels and denies remain untouched because removing them could defeat the backend's confinement or an intentional user policy.
 
 Both extracted and recovery scripts are user-writable, so this workflow never recommends elevating them. Missing unconfined WRITE_DAC stops the workflow for permission-policy review. Automatic recovery can itself fail and cannot survive process termination; reports retain pending recovery commands rather than promising an atomic transaction. The operator keeps those artifacts until verification of the original confined operation succeeds.
 

.agents/notes/implemented/feature/2026-08-08-windows-acl-restricted-token-sandbox.zh.md

@@ -17,7 +17,7 @@ Status: implemented
 
 内置诊断技能在受限令牌之外执行保留原有权限的 ACL 修复，因为受限令牌无法检查发生冲突的对象。外部 PowerShell 需要实际脚本文件，因此注册时从 ASAR 或 SEA 提取资源，而不提供归档内路径。fiber 拥有该临时副本。恢复文件保存在调用者指定的持久输出目录中，确保技能释放后仍能恢复 DACL。
 
-修复在修改前备份，并验证有效权限或生成的 ACE。失败调用按相反顺序恢复尝试修改的内容，且仍视为失败：授权失败后继续操作，会在前置条件尚未满足时移除访问权限。继承的包条目从显式来源处修复，保持继承不变；来源信息不完整或超出范围时不做修改。标签与拒绝条目保持不变，因为移除它们可能破坏后端隔离或用户有意设置的策略。
+修复在修改前备份，并验证有效权限或生成的 ACE。一次调用会完成它能证明的全部修复，因此单个沙箱失败只需一次批准，而不必先诊断再修复：为链路上缺少有效 `WRITE_DAC` 或 `WRITE_OWNER` 的目录添加调用者自身的完全控制 ACE，并在来源处移除显式的包允许 ACE。授权根目录本身也可以被修改和恢复，因此工作区根目录能自我修复并回滚；恢复产物为每个被修改对象一份 DACL 记录和一份恢复脚本副本。当请求的目录正是调用者无法授权的那一个——即授权失败错误所指向的对象——同一次调用还会通过受上限约束、并在截断时如实报告的遍历，检查其子树中的显式包允许 ACE，因为冲突条目常常位于被报告的根目录之下。失败调用按相反顺序恢复尝试修改的内容，且仍视为失败：某次修改失败后继续操作，会在前置条件尚未满足时移除访问权限。继承的包条目从显式来源处修复，保持继承不变；来源信息不完整或超出范围时不做修改。标签与拒绝条目保持不变，因为移除它们可能破坏后端隔离或用户有意设置的策略。
 
 提取的脚本和恢复脚本均可由用户写入，因此此流程绝不建议提权运行它们。不受限调用者缺少 WRITE_DAC 时，流程停止并交由权限策略审查处理。自动恢复本身也可能失败，且无法跨进程终止继续执行；报告保留待执行的恢复命令，不承诺原子事务。操作者应保留这些文件，直到原始受限操作验证成功。