fix(sandbox): correct cmd descendant handling and protected ACL policy

Replace the earlier cmd-wide descendant incompatibility diagnosis with the verified distinction between drive-qualified paths and PATH/workspace-relative invocation. Document the cmd YAML configuration, executable resolution, --no-runtime approval flow, and safe descendant invocation examples in the user README.

Keep the System32 protected DACL intact for both the OS Runtime Root and approved entry files nested below it. Skip redundant file-level ACL rewrites for approved System32 executables while retaining LPAC confinement, resolved-path checks, SHA-256 approval, WFP policy, and Job Object enforcement.

Expand Windows coverage with capability positive/negative matrices, protected-DACL regression tests, cmd/PowerShell/venv Python script execution, nine Entry-to-Descendant combinations, network none/local probes, and randomized ACL round-trip testing. Add read-only CLI/README verification and published HTTP MCP agent_run verification scripts.

Update Design, Audit Report, and Requirement Traceability with the corrected root cause, current evidence, withdrawn diagnostic conclusions, and the remaining partial item for per-combination descendant self-recorded LPAC SID/Job evidence.

Verified: Release build 0 warnings/errors; Core 103 PASS; Planner 10 PASS; Windows 75 PASS with skip 0; README operational suite 19 PASS; published HTTP MCP agent_run completed 3/3 with cmd, curl, C:\tmp\.venv Python, network-none enforcement, ACL restoration, and CMD_HTTP_MCP_OK.

1 files changed, 12 insertions, 0 deletions

diff --git a/doc/AuditReport.md b/doc/AuditReport.md
index 47ee218..b176260 100644
--- a/doc/AuditReport.md
+++ b/doc/AuditReport.md
@@ -12,6 +12,18 @@ commit `37386b8`に対する2026-08-11の再監査結果は履歴として以下
 - Entry ProcessだけをApproval対象とし、Descendant Processは個別Approvalなしで同じLPAC identity、ACL、WFP、Job confinementを継承する。
 - 2026-08-12の最終working-tree検証でRelease buildはwarning 0/error 0、Core 103件、Planner 10件、Windows Security/Recovery 53件がすべてPASS、skip 0。`deepseek-v4-flash:cloud` + `think:true` + Python 3.14.3によるstdio、HTTP IPv4、HTTP IPv6 Operational E2EもすべてPASSし、各経路で複雑なPython実装、子Python、独立unittestを完走した。Task終了後のJournal、backup、published process残留は0。証跡は`artifacts/evidence/sandbox-usability-final-working-tree-2/`に保存した。
 
+## 2026-08-13 LPAC Descendant互換性再監査
+
+`cmd.exe`から`curl.exe`を起動できない事象をEntry×Descendantで再調査した。最初のmatrixは`%ComSpec%`や`%SystemRoot%\System32\curl.exe`などドライブ修飾絶対pathを使用しており、その失敗をcmdのDescendant生成拒否と誤認していた。追加調査では、LPAC上のcmdから`cmd.exe /d /c exit 0`と`curl.exe --version`が成功した。絶対pathの場合はcmdが子Process生成前に`GetVolumeInformationW("C:\")`を呼び、そのアクセスが拒否されていた。したがって、cmdおよびLPAC/no-breakaway Process Tree一般の非互換性ではない。
+
+MicrosoftのAppContainer資料は、unpackaged Win32 processをAppContainerで起動する方法と子のtoken継承を説明するが、任意のWin32 Executable組合せの動作互換性までは保証していない。LPACは`ALL APPLICATION PACKAGES`由来accessをopt-outするため、必要capabilityを明示選定する必要がある（[Launch an AppContainer](https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer)、[AppContainer for legacy applications](https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-for-legacy-applications-)）。またJob Objectではbreakawayを許可しない構成がProcess Tree監視を維持する方式であり、breakawayを許可すると子がJob外になる（[Job Objects](https://learn.microsoft.com/en-us/windows/win32/procthread/job-objects)、[Process Creation Flags](https://learn.microsoft.com/en-us/windows/win32/procthread/process-creation-flags)）。
+
+`lpacAppExperience`はMicrosoft Learn/Windows SDKで権限範囲を確認できないため採用しない。限定実験の変更も撤回した。Job breakaway、通常AppContainer fallback、System32 protected DACL解除はいずれもSecurity Boundaryを弱めるため採用していない。
+
+是正として、誤ったcmd専用エラー分類と失敗を期待するtestを撤回し、protected DACLとの両立規則、capability採用基準、Entry×Descendant×System32 utilityの組合せmatrixをDesignへ追加した。cmdのtestはPATH解決名またはWorkspace相対pathで実際のDescendant起動とNetwork通信を検証する。また、HTTP MCP実動作でSystem32 rootを除外しても配下のApproved `cmd.exe` fileへ個別ACLを適用していた実装漏れを検出したため、OS Runtime Root配下全体をDACL変更対象外とした。Network capabilityなし／ありの両条件ではRegistry read、Registry write拒否、COM拒否、Broker secret非継承も組合せ検証した。
+
+是正後はREADME/CLI/Windows operational suite 19件とAgent.Windows全75件が管理者・skip 0でPASSした。最新publish BundleのHTTP MCP `agent_run`もcompleted 3/3となり、cmdから非修飾`cmd.exe`、非修飾`curl.exe`、Workspace相対`C:\tmp\.venv` Pythonを起動し、Network `none`の遮断と`CMD_HTTP_MCP_OK`を確認した。全9組の子Process自身によるLPAC SID/Job個別記録は未実施のため、対応するTraceability項目だけはPARTIALとして残す。
+
 ## 確認した矛盾と是正
 
 | 観点 | 監査時の状態 | 是正 |