fix: harden Grok hooks and release v1.17.9

Author: rockyshi1993

CHANGELOG.md

@@ -1,16 +1,17 @@
 # 变更日志 (CHANGELOG)
 
 > **说明**: 版本概览摘要；历史版本见对应详细变更文件。
-> **最新版本详细变更文档**: [`changelogs/releases/v1.17.8.md`](./changelogs/releases/v1.17.8.md)
-> **最后更新**: 2026-08-16
-> **当前版本**: v1.17.8 以稳定 Hook launcher 消除升级信任漂移，为未分发宿主事件的 SkillRoute 增加结构化 `profile_context_plan` 自举回退，保持多项目 pending/复合 content 权威一致，并以当前身份不变量验证动态 capability；版本发布权威以对应 Git tag、npm registry 与 GitHub Release 为准。
+> **最新版本详细变更文档**: [`changelogs/releases/v1.17.9.md`](./changelogs/releases/v1.17.9.md)
+> **最后更新**: 2026-08-17
+> **当前版本**: v1.17.9 修复 Windows Grok Hook 的 PowerShell 命令解析，收敛为插件唯一 lifecycle Owner，并补齐事务、临时目录、Memory/Profile current-truth 与发布链回归；版本发布权威以对应 Git tag、npm registry 与 GitHub Release 为准。
 
 ---
 
 ## 版本概览
 
 | 版本 | 日期 | 变更摘要 | 详细 |
 |------|------|---------|------|
+| [v1.17.9](./changelogs/releases/v1.17.9.md) | 2026-08-17 | 🔧 **Grok Hook 启动与唯一 Owner 修复**：Windows canonical transport 兼容 PowerShell；用户级 Grok Hook 退役受管 lifecycle 声明，由插件独占六事件；verifier 分离物理声明、精确去重结果与 mutation owner，并同步事务、workspace temp、Memory/Profile 发布链闭环 | [查看](./changelogs/releases/v1.17.9.md) |
 | [v1.17.8](./changelogs/releases/v1.17.8.md) | 2026-08-16 | 🔧 **宿主稳定入口与 SkillRoute 自举修复**：Hook 信任身份与不可变 runtime generation 解耦；Codex 未分发 UserPromptSubmit 时由结构化 MCP 回退建立同一 SkillRoute envelope；多项目 pending 保留 exact host/显式 Skill，ContextRead 拒绝用 sidecar 覆盖复合返回体失配；S15 兼容 Hook/MCP 两种证据形态并绑定真实入口，closure 复算当前 runtime/adapter/evidence | [查看](./changelogs/releases/v1.17.8.md) |
 | [v1.17.7](./changelogs/releases/v1.17.7.md) | 2026-08-15 | 🔧 **全局运行态一致性与首载闭环修复**：正文读取绑定持久计划并在源层有界；未解析目标、catalog sidecar、Memory 状态、配置 CAS/Readiness、命令/对象身份与 CLI/Desktop 证据分层完成跨消费者收敛；Windows Node 18 插桩递归与验证预算假失败已关闭 | [查看](./changelogs/releases/v1.17.7.md) |
 | [v1.17.6](./changelogs/releases/v1.17.6.md) | 2026-08-14 | 🔧 **SkillRoute 最终 Stop 完备性修复**：非显式未提交路由在最终回复前返回 exact catalog action，阻止自然语言 workspace Skill 被无工具回复静默跳过；统一路由与宿主能力边界保持不变 | [查看](./changelogs/releases/v1.17.6.md) |

README.md

@@ -159,6 +159,8 @@ devcodex grok
 
 `devcodex grok` 是 Grok Full 入口：它会加载用户级控制内核、项目绑定、MCP 与渐进式 SkillRoute。直接运行普通 `grok` 是 Partial 兼容入口；它仍可使用用户级规则、MCP 和可用 Hook，但 UserPromptSubmit 属于被动提示面，不能据此宣称与 Full 启动注入完全等价。
 
+Full 入口只有在 SkillRoute bootstrap 明确 active 后才会物化提示并启动 Grok；bootstrap error/inactive 分别以 `GROK_FULL_BOOTSTRAP_ERROR` / `GROK_FULL_BOOTSTRAP_INACTIVE` 失败关闭，不会遗留 child 或 prompt snapshot。Grok SessionStart 的诊断临时目录使用 `GrokSessionPrivateOwnerV1`：每次启动都有 nonce owner，即使宿主未给 sessionId 也不会共享固定目录；只有 owner 已证死亡且 TTL 到期的目录才可进入恢复，诊断记录不保存 prompt 正文。
+
 Cursor 当前是第六宿主 Beta。全局安装会写入用户级 `~/.cursor/hooks.json` 和 DevCodex Cursor Plugin；本地 IDE、交互 CLI 与 Headless CLI 共享 Hook、Plugin、MCP 和渐进式 SkillRoute。Cursor Cloud Agent 不加载用户级 Hook，因此只标记为 Partial / `UNVERIFIED`，不会继承本地 readiness 结论。能力依据见 [Cursor Hooks](https://cursor.com/docs/hooks)、[Cursor Plugins](https://cursor.com/docs/plugins) 与 [Cursor Headless CLI](https://cursor.com/docs/cli/headless)。
 
 Cursor 与 Grok 同机安装时，`devcodex grok` 只在它启动的 Grok 子进程中关闭 Grok 对 Cursor Hooks 的兼容导入，避免 Grok 二次解析 `~/.cursor/hooks.json`；Cursor 官方 Hook 配置不会被改写，用户直接运行普通 `grok` 时的兼容偏好也不会被永久修改。
@@ -419,6 +421,12 @@ devcodex grok
 
 在目标项目目录中新建 Grok 会话后再验证。若 `status` 显示 `Grok parity full-capable — use: devcodex grok`，这正是在提示应走 Full 入口；它不是权限不足，也不要求永久开启完全访问。
 
+### Grok Hook 出现 PowerShell `ParserError`，或同一 DevCodex Hook 显示两份来源怎么办？
+
+升级到 `devcodex >= 1.17.9`，再执行 `devcodex global-adapters apply` 并新建 Grok 会话。Windows 上的受管 Hook 命令会通过同一个跨 `cmd.exe` / PowerShell 的稳定启动格式进入 Node；Grok 用户级全局 Hook 文件只保留委派说明和用户自有 Hook，六个 DevCodex lifecycle 事件由 `devcodex-workspace` plugin 单独声明。Grok 默认导入 Claude Hook 时，DevCodex Claude launcher 会根据 Grok 保留的事件、Hook、session 与 workspace 四项环境指纹在读取回执前静默退出。
+
+Grok 会对来自不同来源但命令完全相同的 handler 做精确去重，因此“全局文件与 plugin 都能看到同一条命令”不等于已经发生两次状态写入；但这仍是脆弱的双声明拓扑，命令一旦漂移就可能成为两个有效 handler。`doctor` 从 v1.17.9 起分别核对物理声明数、精确去重后的有效 handler 数和 lifecycle owner 数，目标均为 plugin 单声明、单 handler、单 owner。无需在 `~/.grok/config.toml` 中关闭整个 Claude 兼容层；用户自有 Claude/Grok Hook 继续保留。
+
 ### “帮我审批”时反复重新连接，是否必须开启完全访问？
 
 不需要永久开启 Full access。“帮我审批”仍受 workspace 沙箱约束；它只决定符合条件的越界动作如何审批，不会自动扩大文件系统或可执行文件范围。先运行：
@@ -461,10 +469,13 @@ devcodex doctor
 
 ```bash
 devcodex tmp status
-devcodex tmp prune --dry-run
+devcodex tmp status --project=<project> --partition=runs
+devcodex tmp maintain --project=<project> --partition=runs
 ```
 
-只有带 `WorkspaceTempManifestV1`、owner/type 可识别、TTL 已到期、没有活动 lease，且备份事务已完成的对象才会成为候选。确认后再执行 `devcodex tmp prune --apply`。一次状态检查的 canonical 文件/目录与 legacy 目录观察共用 10,000 项相关对象上限；四个 artifact 分区根不能被 manifest 整体认领，unknown owner、共享/损坏 lease、未知分区、lock、reparse point、路径逃逸、不完整备份和扫描截断都会保持 blocked。DevCodex 只拥有 `.tmp/devcodex/`：`.tmp/` 容器、`.tmp/<other-producer>/`、工作区根的 `tmp/.tmp-*` 以及 `.tmp.drive*` 外部传输 spool 都不进入 DevCodex ownership、blocked 列表或 `--apply` 删除集合；它们必须由各自生产者盘点并取得独立删除授权。
+新 writer 只创建 `WorkspaceTempManifestV2`：先分配 manifest/owner token，再写目标，路径按 canonical root 保存为可重定位相对身份，生命周期为 allocated → active → finalized/abandoned。`WorkspaceTempManifestV1` 只读兼容，不能登记新对象或自动获得 V2 清理权限。状态读取按 project/partition 分页；返回 `WorkspaceTempCursorV1` 时必须原样用于同一 scope，单个 scope 不完整不会阻断其他完整 scope。
+
+`tmp maintain` 默认只生成带 quota/watermark 的 plan/receipt，自动或 opportunistic 调度也固定为 plan-only，不删除文件。只有 owner/type/target identity 可验证、TTL 已到期、token-bound lease 不活动且备份事务完成的 V2 对象才会成为候选；确认精确清单后，实际清理仍必须显式给出一个完整 scope，例如 `devcodex tmp maintain --apply --project=<project> --partition=runs`。`tmp prune` 保留为兼容别名并服从相同约束。unknown owner、共享/损坏 lease、普通伪造 lock、reparse point、路径逃逸、不完整备份或 scope 截断都会保持 blocked。DevCodex 只拥有 `.tmp/devcodex/`；兄弟 producer、外部传输 spool 与 legacy 内容仅报告。
 
 ### 为什么全局安装包里没有源码仓的全部 `test:*` / 发布脚本？
 
@@ -515,11 +526,18 @@ devcodex runtime prune --dry-run
 
 ```bash
 devcodex tmp status --json
-devcodex tmp prune --dry-run
-devcodex tmp prune --apply
+devcodex tmp status --project=<project> --partition=runs --json
+devcodex tmp maintain --project=<project> --partition=runs
+devcodex tmp maintain --apply --project=<project> --partition=runs
 ```
 
-`tmp prune` 无参数时等价于 `--dry-run`。所有布局的 canonical root 都是 `<workspace>/.tmp/devcodex/`，按 `runs/cache/backups/leases/quarantine/manifests` 分区；安装器和宿主配置备份会先验证 canonical/partition 非 reparse，再写入 `backups/<project>/` 并登记保留期限。对象删除时会同步回收其唯一且已过期的 lease；共享 lease 保持 blocked。旧 `.devcodex/**/.tmp` 和没有 manifest 的历史内容只报告，不会被自动迁移或删除。
+`tmp maintain` 与兼容的 `tmp prune` 无 `--apply` 时都是 plan-only。apply 必须指定一个 inventory 与 orphan scan 均完整的 project/partition scope；跨 scope、带分页 cursor 或不完整范围不能删除。所有布局的 canonical root 都是 `<workspace>/.tmp/devcodex/`，按 `runs/cache/backups/leases/quarantine/manifests` 分区；安装器和宿主配置备份会先验证 canonical/partition 非 reparse，再写入 `backups/<project>/` 并登记保留期限。对象删除时只回收其唯一且已过期的 token-bound lease；共享 lease保持 blocked。旧 `.devcodex/**/.tmp`、V1 manifest 和没有 manifest 的历史内容只读报告，不会被自动迁移或删除。
+
+### Memory MCP 的分页和写入回执
+
+`memory_session_query` 与 `memory_summary_query` 首次调用可省略 cursor；结果仍有下一页时会返回 `MemoryPaginationV1.nextCursor`。这个 opaque `MemoryCursorV1` 同时绑定工具、项目/active-root、ContextRead binding、查询条件、来源身份与 offset，下一页必须原样回传；来源或绑定变化会稳定拒绝，不能静默退回第一页，partial source 也不会签发不安全的下一页 cursor。
+
+`memory_session_allocate`、`memory_session_write` 与 `memory_summary_append` 的文件提交由同一个 CAS owner 完成。成功写入返回 `MemoryFileTransactionReceiptV1`，记录提交前后摘要、final CAS、flush/readback、字节读写与 metadata 结果；已有文件的纯 EOF 增长使用 append fast path，中段更新才走原子 rewrite。POSIX mode/owner 必须保留，新文件为 0600；Windows DACL 未直接取证时明确保持 `WARN/UNVERIFIED`。
 
 ## 生效方式
 

RULES.md

@@ -1,6 +1,6 @@
-# DevCodex v1.17.8 — 使用入口
+# DevCodex v1.17.9 — 使用入口
 
-> AI workflow injector for Copilot / Claude Code / Codex / Gemini / Grok / Cursor Beta · publisher: Rocky · version: 1.17.8
+> AI workflow injector for Copilot / Claude Code / Codex / Gemini / Grok / Cursor Beta · publisher: Rocky · version: 1.17.9
 
 ## 正式主支持客户端
 

changelogs/releases/v1.17.9.md

@@ -0,0 +1,26 @@
+# DevCodex v1.17.9
+
+> 发布日期：2026-08-17
+> 类型：Patch / Grok Hook 启动、所有权与发布链闭环
+
+## 发布摘要
+
+v1.17.9 聚合 v1.17.8 发布后已经核实的失败关闭、事务/CAS、workspace temp V2、Memory 与 Profile current-truth 修复，并关闭 Windows Grok Hook 启动与 lifecycle 所有权问题。
+
+## Grok 修复
+
+- Windows 受管 Hook 命令改为 `cmd.exe /d /s /c call <node> -e ...` 的 canonical transport；同一命令可从 `cmd.exe` 和 Grok 使用的 PowerShell 启动，Node 接收的 argv 保持不变。
+- 用户级 `~/.grok/hooks/devcodex.json` 不再声明 DevCodex lifecycle handler，只保留委派说明和合并后仍属于用户的 Hook；六个事件由 `devcodex-workspace` plugin 单独声明。
+- verifier 新增 `GrokLifecycleOwnerTopologyV1`，独立报告物理声明数、Grok 精确去重后的有效 handler 数和 mutation owner 数，防止双来源依赖隐式去重形成脆弱拓扑。
+- Grok 默认导入 Claude Hook 时，DevCodex Claude stable launcher 必须同时观察到 `GROK_HOOK_EVENT`、`GROK_HOOK_NAME`、`GROK_SESSION_ID`、`GROK_WORKSPACE_ROOT` 才会在读取 receipt 前静默退出；缺任一指纹都不会误跳过原生 Claude 生命周期。
+
+## 兼容性与边界
+
+- 不要求修改 `~/.grok/config.toml` 或关闭整个 Claude 兼容层。
+- 用户自有 Grok/Claude Hook 保留；portable Grok 模板继续携带独立 lifecycle 能力。
+- Grok 对跨来源完全相同的命令会精确去重，因此旧安装的双声明不被误报为已经发生两次 mutation；修复目标是消除双声明和未来命令漂移风险。
+- 不新增第三方依赖、网络服务、端口或常驻进程。
+
+## 验证与发布
+
+发布资格要求 targeted Hook/config/runtime-verifier 回归、六宿主 global install/update、完整测试、coverage、audit、Profile、package/consumer smoke 全部通过；随后按 main CI、annotated tag、Publish、npm/GitHub Release、fresh registry install 和本机更新顺序完成 R5～R7。最终 commit、run、制品摘要及真实 Grok replay 以发布报告和 Profile current truth 为准。

changelogs/unreleased.md

@@ -1,11 +1,12 @@
 # 未发布变更（Unreleased）
 
 > **用途**: 记录尚未正式发版的实现级变更。
-> **当前**: v1.17.8 宿主稳定入口与 SkillRoute 自举修复已通过源码 R4 并冻结为发布候选；正式发布事实仍以 Git tag、npm registry 与 GitHub Release 为准。
+> **当前**: v1.17.8 已发布；v1.17.9 已获 `@rocky` 发布授权并处于本地资格验证阶段。远端 tag、npm 与 GitHub Release 完成前仍只属于候选，当前发行事实由 Profile 05 的 `ProfileCurrentTruthV1` 对照 package、workflow、npm 与 GitHub。
 
 ## 当前未发布实现候选
 
-- **v1.17.8 宿主稳定入口与 SkillRoute 自举修复候选（PI-251～255 / PF-303～307）**：六宿主 Hook 改为稳定 launcher，由 committed receipt 安全转发到当前不可变 runtime，避免每次升级改变 Codex Hook 信任身份；`profile_context_plan` 在宿主没有分发 UserPromptSubmit 时返回并复用精确 SkillRoute bootstrap，并把多项目 pending 的 canonical hostVariant/显式 Skill 保真带入 MCP；ContextRead 对复合 content 选择唯一主 schema，拒绝用 sidecar 覆盖可观察的身份失配；S15 归一化 Hook history 与结构化 receipt，并以 evidence-bound hostVariant 阻止 Desktop ambient 污染 CLI；closure 与安装态全局配置回归以当前 runtime、入口专属 adapter 与 portable evidence 不变量替代阶段性零 PASS/UNVERIFIED 快照。Codex/Grok 源码 S15 已按 R-19 后 runtime 重新通过，Desktop 当前任务仍保持 UNVERIFIED。完整说明见 `changelogs/releases/v1.17.8.md`。
+- **v1.17.9 聚合发布候选**：纳入 v1.17.8 发布后已核实的 35 项失败关闭、事务/CAS、workspace temp V2、Memory 与 Profile current-truth 修复；同时修复 Windows Grok 通过 PowerShell 执行受管 Hook 时首个引号可执行文件被解析为字符串而触发 `ParserError`，统一使用可被 `cmd.exe` 与 PowerShell 接受的稳定 Node 启动命令。Grok 用户级全局文件退出 DevCodex lifecycle 声明，六事件由用户级 `devcodex-workspace` plugin 单独拥有；runtime verifier 分别核对物理声明、Grok 精确去重后的有效 handler 与 mutation owner。Grok 默认导入 DevCodex Claude Hook 时，稳定 launcher 依据四项 Grok 保留环境指纹在回执读取前静默退出；用户自有 Hook、Grok Claude 兼容偏好、portable 模式与其他五宿主语义不变。完整说明见 `changelogs/releases/v1.17.9.md`。
+- **v1.17.8 宿主稳定入口与 SkillRoute 自举修复已归档（PI-251～255 / PF-303～307）**：六宿主 Hook 改为稳定 launcher，由 committed receipt 安全转发到当前不可变 runtime，避免每次升级改变 Codex Hook 信任身份；`profile_context_plan` 在宿主没有分发 UserPromptSubmit 时返回并复用精确 SkillRoute bootstrap，并把多项目 pending 的 canonical hostVariant/显式 Skill 保真带入 MCP；ContextRead 对复合 content 选择唯一主 schema，拒绝用 sidecar 覆盖可观察的身份失配；S15 归一化 Hook history 与结构化 receipt，并以 evidence-bound hostVariant 阻止 Desktop ambient 污染 CLI。完整说明见 `changelogs/releases/v1.17.8.md`；正式发布事实以 Git tag、npm registry、GitHub Release 与 `ProfileCurrentTruthV1` 为准。
 - **v1.17.7 全局运行态一致性与首次加载闭环修复已归档**：22 项确认问题及 Windows Node 18 插桩递归、验证预算假失败均已关闭；GitHub CI、Publish、npm/GitHub tarball parity 与六宿主本机更新已经完成。完整说明见 `changelogs/releases/v1.17.7.md`。
 - **v1.17.6 工作区 Skill 非显式 Stop 完备性修复已归档（VL-098 / PF-296 / GR-088）**：非显式 `PLAN_NOT_COMMITTED` 除既有 PreToolUse 外，在最终 Stop 也 fail closed，并复用 `NextActionEnvelopeV1` 返回精确首个 catalog 调用；普通聊天通过统一 catalog 后 `commit(null)` 完成 0/1 决策，Hook 不恢复关键词 auto-match 或新增 final-text classifier。重复 Stop 继续使用现有 3 次饱和与 notice fingerprint，PreCompact、ContextRead allowlist、retirement 与 must-reply 合同不变。完整说明见 `changelogs/releases/v1.17.6.md`；正式发布事实仍以 Git tag、npm registry 与 GitHub Release 为准。
 - **v1.17.5 发布包 npm scripts 闭包修复已归档（PF-294 / GR-086）**：`PublishedPackageScriptsContractV1` 让源码保留完整维护脚本，同时把最终 tarball manifest 投影为 8 个 lifecycle / validate / global-adapters 入口；prepack/postpack 通过摘要收据事务原字节恢复源码 manifest。发布门禁从最终 manifest 建立 direct/nested/require/path.join/spawn 闭包，并执行真实 `pack → 隔离 HOME 安装 → installed validate → installed self-pack`；缺入口、缺依赖、source-only 泄漏、lifecycle 单边、恢复冲突或状态残留均失败关闭。完整说明见 `changelogs/releases/v1.17.5.md`，正式发布事实仍以 Git tag、npm registry 与 GitHub Release 为准。
@@ -118,7 +119,7 @@ WorkspaceDataAbsorptionScopeGate · DocsSiteVisualAcceptanceGate · OmissionOnly
 ### DevCodex V1 全量审计 residual F 项闭环（ISSUE-045 / ISSUE-047 / ISSUE-051 / ISSUE-052 / ISSUE-053 / ISSUE-054 / ISSUE-057，2026-07-20）
 
 - Profile 06 `validation-execution` 证据数字同步当前 validation manifest：64 nodes、fast 59、full 62，避免旧 `54/full 53` 继续误导审计结论。
-- memory MCP 增加 `memory_session_allocate`、active-root/agent/date scoped lock、原子文件替换与 `MemoryTransactionReceiptV1`；memory Skill 增加 `MemoryTransactionWriterGate`，测试覆盖唯一会话分配、事务 receipt、锁冲突 fail-closed 与无半提交。
+- memory MCP 增加 `memory_session_allocate`、active-root/agent/date scoped lock 与 `MemoryFileTransactionReceiptV1`；当前统一文件事务补齐 final CAS、flush/readback、metadata 与 append fast path。memory Skill 的 `MemoryTransactionWriterGate` 覆盖唯一会话分配、事务 receipt、锁冲突 fail-closed 与无半提交。
 - HostParity 发布关键测试不再依赖仓库外 `.devcodex` 运行态文档，改用 tracked fixture；portable Grok SessionStart 对 `GROK_SESSION_ID` 做清洗和 base-boundary check，并增加 hostile replay 防路径越界。
 - workspace deployment manifest 通过 `devcodex update` 重新同步，status/doctor 与 `test:profile-deploy` 的 managed manifest 权威重新一致；Agent SUMMARY 历史违规投影补齐至 runtime alerts=0。