企业官网建设流程全解析

planning-with-files 报 [PLAN TAMPERED — injection blocked] 拒绝注入计划内容怎么处理？

【免费下载链接】planning-with-filesPersistent file-based planning for AI coding agents and long-running tasks. Crash-proof markdown plans, session recovery after /clear and compaction, per-turn re-injection against context rot, deterministic completion gate. Manus-style. Install from npm, the Claude Code plugin marketplace, or npx skills. Codex, Cursor, OpenCode, 60+ agents.项目地址: https://gitcode.com/GitHub_Trending/pl/planning-with-files

在 Claude Code、Pi 等接入了 planning-with-files 的 agent 会话里，如果你给模型发消息后上下文里没有计划内容，取而代之的是这样一行：

[planning-with-files] [PLAN TAMPERED — injection blocked]

这说明钩子检测到当前task_plan.md的内容与已存档的 SHA-256 哈希不一致，于是拒绝把计划正文注入模型上下文。这是 attestation 机制按设计工作的结果，不是安装损坏：v2.37.0 起，运行/plan-attest后，每次 UserPromptSubmit 和 PreToolUse 钩子触发时都会重算task_plan.md的哈希并与存档值比对，比对失败就阻断注入（见 commands/plan-attest.md）。

处理目标只有一个：让计划文件与 attestation 重新一致，恢复每轮注入。

先读报错，判断是哪个分支

在 userprompt 触发场景下，阻断消息本身携带排查所需的信息（来自scripts/inject-plan.sh的输出）：

[planning-with-files] [PLAN TAMPERED — injection blocked] expected=<attestation 文件中记录的哈希> actual= <当前 task_plan.md 的实际哈希> Run /plan-attest to re-approve current contents, or restore the file from git.

文档给出的出口只有两条：确认自己确实改过计划后重新 attest，或者从 git 恢复被改动的文件。先用/plan-attest --show查看当前存档的哈希和存放位置（并行计划模式在.planning/<active-plan>/.attestation，legacy 模式在./.plan-attestation），确认 attestation 确实存在后再分情况处理。

情况一：你自己编辑过计划，重新 attest

这是最常见的情况——计划定稿后你（或协作的另一个 agent 会话）又改了task_plan.md，但没重新批准。处理命令：

/plan-attest

等价的脚本调用是sh scripts/attest-plan.sh（Linux/macOS/Git Bash）或& "$env:CLAUDE_PLUGIN_ROOT\scripts\attest-plan.ps1"（Windows PowerShell 插件安装）。注意：每次你有意编辑并重新批准计划后都要重跑这条命令。

如果你设置了PLAN_ID或PWF_PLAN_ROOT显式选择器，且它无法解析到计划，attest 脚本会直接报错退出，而不会回退去 attest 另一个计划（见 docs/attestation-locking.md）。多个计划并存时，用PLAN_ID固定目标计划：

export PLAN_ID=2026-01-10-backend-refactor sh scripts/attest-plan.sh

情况二：你没改过计划，文件被意外改动

如果expected与actual不一致但你没有编辑过task_plan.md，说明文件被工具输出、协作者或其他 bug 改写了——这正是 attestation 要拦截的场景。此时不要急着重新 attest（那等于批准了被篡改的内容），先按报错提示从 git 恢复文件，再重跑/plan-attest校验哈希是否回到预期值。

情况三：想让计划回到可自由编辑状态

如果你还在迭代计划、不想被哈希锁定，移除 attestation：

/plan-attest --clear

--clear移除 attestation 文件，计划重新开放编辑；需要重新锁定后再运行一次/plan-attest。

验证：用 plan-doctor 确认注入恢复

重新 attest 后，在项目根目录运行自检脚本（只读诊断，不写任何文件，总是以退出码 0 结束）：

sh scripts/plan-doctor.sh

看injection一行（示例输出，字节数随计划内容变化）：

PASS injection: emits plan context (1234 bytes)

出现PASS ... emits plan context说明计划内容已正常进入注入通道。如果仍报：

WARN injection: plan is attested but the hash mismatches — run /plan-attest (or scripts/attest-plan.sh) to re-approve the current plan

则回到"情况一/二"重新核对。plan-doctor 还会报告 attestation 文件是否位于钩子查找的位置（.planning/<dir>/.attestation或根目录.plan-attestation），可用于排除"attest 到了错误目录"的问题。

在 Pi 中，同样的排查路径是/plan-attest --show后视情况/plan-attest，Pi 扩展读取的是与 Claude Code 完全相同的.attestation文件，attest 一次在两个运行环境同时生效（见 docs/pi-agent.md）。

已知误报：先查版本再动手

如果你的task_plan.md确实没变却每次都报[PLAN TAMPERED]，可能是已修复的历史 bug，升级即可：

• v3.9.0（2026-08-01）：PWF_PLAN_ROOT绝对路径绑定下，GNUsha256sum对需要转义的文件名（Windows 风格路径会触发）在输出行前加反斜杠，导致解析出的摘要永远与 attestation 不匹配，每次触发都报篡改。
• v3.8.0（2026-07-21）：SHA 缓存键曾只用相对计划路径，同一台机器上所有 legacy 根项目共享一个缓存槽，另一个项目的旧缓存可能让本项目误报篡改。缓存键现在包含绝对项目根，升级后每个计划会多一次重新哈希，缓存自愈。
• 更早版本中attest-plan.sh非原子写 attestation，偶发产生截断或零长度文件，下一次钩子触发即误报篡改。现在的实现是写临时文件再原子重命名，flock可用时用flock -w 5包裹重命名（见 docs/attestation-locking.md）。

升级后仍误报时，再按前文的--show/ plan-doctor 流程定位。

边界说明

attestation 存档的是普通本地摘要，不是带密钥的签名或人工批准证明：任何能同时改写task_plan.md和.attestation的进程都能让新内容通过校验；计划内容与工具结果、外部来源一致也不代表内容可信（docs/attestation-locking.md 的 Trust boundary 一节）。它的价值是拦截"计划被静默改写"这一类变化，而不是为计划内容本身背书。

【免费下载链接】planning-with-filesPersistent file-based planning for AI coding agents and long-running tasks. Crash-proof markdown plans, session recovery after /clear and compaction, per-turn re-injection against context rot, deterministic completion gate. Manus-style. Install from npm, the Claude Code plugin marketplace, or npx skills. Codex, Cursor, OpenCode, 60+ agents.项目地址: https://gitcode.com/GitHub_Trending/pl/planning-with-files