背景

承接 repo-evolver CLAUDE-FABLE-5 透镜第 5 轮（iteration 20 SCAN）。前 4 轮（iteration 17–19）只在 planner 侧注入了外部知识纪律（#360 已合并），但深扫发现 code-generation 提示词系统——FrontAgent 真正写出前端代码的那一层——完全未应用同等纪律。

问题（已核实，非误报）

packages/core/src/llm/code-generation.ts 是把 LLM 输出转成最终文件代码的核心提示词层：

• generateCodeForFile（:58）和 generateModifiedCode（:146）两条 system prompt
• grep -c "PROGRESSIVE_EXPLORATION\|EXTERNAL_KNOWLEDGE" packages/core/src/llm/code-generation.ts → 0 命中

当前 code-gen system prompt 只有泛化要求「遵循最佳实践 / 代码清晰可维护 / 使用 TypeScript 类型」（:101-105、:164-168），没有任何「不要凭部分印象臆测 API 形状」的纪律。这正是代码生成层最容易产生幻觉（hallucinate）的地方：编造不存在的库 API、猜测版本特定的默认行为、过时的 prop 签名。

planner 已被告知「遇到不熟悉/版本特定的库先 web_fetch 权威来源」（iteration 17 的 EXTERNAL_KNOWLEDGE_PROTOCOL，#360/b4b113fd），但 planner 生成的步骤里 codeDescription 只是一段描述；真正把这段描述展开成代码的 generateCodeForFile，其 system prompt 并不知道这条纪律——于是即便 planner 安排了 web_fetch 核实，代码生成这一步仍可能凭记忆写错 API。纪律在 planner 断了链。

学习自 CLAUDE-FABLE-5 的具体模式

CLAUDE-FABLE-5.md 的 ### core_search_behaviors / ### critical_reminders 反复强调一个底层原则（非搜索专用，而是认识论原则）：

对不熟悉、版本特定、最近才出现的库/框架/API，默认不能凭部分印象作答，必须先核实；对已熟知且稳定的知识则无需反复核实（反向约束防无谓开销）。

这正是 FrontAgent 已有的 EXTERNAL_KNOWLEDGE_PROTOCOL 常量（packages/core/src/llm/prompts.ts）所编码的内容。问题只在于该常量目前只注入了 planner 的两条 system prompt，没注入 code-gen 的两条。

提议（最小增量，prompt-only）

将现有 EXTERNAL_KNOWLEDGE_PROTOCOL（不新增常量，复用 iteration 17 已稳定的措辞）注入 generateCodeForFile 与 generateModifiedCode 的 system prompt，使 code-gen 层与 planner 层共享同一外部知识纪律。

理由（为什么不新写措辞）：

• 已稳定的 EXTERNAL_KNOWLEDGE_PROTOCOL 经 feat(prompts): 为 planner 注入"先核实再假设"的外部知识纪律（从 CLAUDE-FABLE-5 学习 web_fetch when-to-use） #360 的 repo-guard 5/5 评审 + 82 行测试 + CI 全绿，措辞已收敛。
• planner 与 code-gen 共享同一纪律 = 纪律链路闭合：planner 决定「要不要核实」→ code-gen「按核实过的事实写码 / 存疑时在 codeDescription 里标注」，而非两套不同措辞。

范围

只改 packages/core/src/llm/code-generation.ts 两条 system prompt（追加协议段）。
不改：executor、schemas、工具路由、web_fetch 行为、planner、常量定义、回归温度/maxTokens。web_search 仍明确不在范围（需 provider/key，单列）。

耦合度判定

高耦合（与 code-gen 内部 system prompt 深度绑定）→ 直接在 FrontAgent 内集成，不另开仓库（同 #360 判断）。

GitNexus 影响预估

generateCodeForFile / generateModifiedCode 上游 callers：llm-service.ts:371/393（薄封装）→ executor-skills.ts:197/263（create/modify step 执行）。本次仅改 system prompt 字符串插值，不改签名/返回类型/schema → 预期 impact LOW（无 call-edge 变化，纯 prompt 文本增量）。code-generation.test.ts 仅覆盖 parseTypeScriptErrors，不触及 prompt 字符串 → 不破坏现有 characterization。

验收标准

1. generateCodeForFile 的 system prompt 包含 EXTERNAL_KNOWLEDGE_PROTOCOL 全文（grep / 测试断言）。
2. generateModifiedCode 的 system prompt 同样包含。
3. EXTERNAL_KNOWLEDGE_PROTOCOL 复用 prompts.ts 现有常量（import，不复制粘贴，避免措辞漂移）。
4. 新增针对性测试：packages/core/src/llm/code-generation.test.ts 断言两条 system prompt 均注入协议且含关键语义（不熟悉/版本特定 → 以核实为准 / 稳定知识无需 fetch 的反向约束）。
5. pnpm quality:precommit（lint + typecheck + test + test:workflows）全绿。

GitNexus Impact Summary

• Risk level: LOW（prompt 文本增量，无签名/schema/call-edge 变更）
• Critical skeleton changes: 无
• GitNexus impact: 改动符号 generateCodeForFile/generateModifiedCode（packages/core/src/llm/code-generation.ts）。upstream direct callers = llm-service.ts 两处薄封装 → executor-skills.ts 两处 step 执行；无跨包契约面变化。实现时补 detect_changes 实测结果。
• Verification: typecheck + biome + 受控 diff + 针对性单测（prompt 注入断言）。