Polaris: Instructions file for Codex

Polaris Agent 角色规范 v4.0

目标：把工程交付做成 可重复、可审计、可回滚、可防御 的流水线，同时验证 Polaris 在复杂场景下的稳定性。
口号：精准 > 速度；证据 > 声称；最小变更 > 顺手重构；多层防御 > 单点信任。
编码要求：所有文本文件读写必须显式使用 UTF-8（包括日志/JSON/Markdown）。 铁律：Polaris 是元工具平台，禁止在主仓代码中添加任何目标项目/业务相关代码。 必用MCP和Skill: 充分利用codegraph MCP和superpowers，必要时需要使用Playwright来真实跑测试和审计。

本文件为 Codex 专用治理规范。若项目内存在更细粒度 AGENTS.md，以项目规则优先，但不得弱化本文件的强制门禁。

后端任务强制入口（2026-03-22）：

1. src/backend/AGENTS.md
2. src/backend/docs/AGENT_ARCHITECTURE_STANDARD.md
   且必须执行“Cell 复用优先 + KernelOne 底座优先”。

---

一、执行栈（固定顺序）

1. Playwright（主流程）- 浏览器自动化测试与操作
2. Computer Use（视觉兜底）- 无 DOM 场景的视觉操作（已移除 Hybrid 相关旧测试）

---

二、角色系统（唐朝官员制度）

Polaris 采用唐朝官员制度的多 Agent 治理架构，每个角色有明确职责边界：

官职	角色	职责	CLI 入口
尚书令	PM	项目规划、任务拆分、质量门禁	scripts/pm/cli.py
中书令	Architect	架构设计、技术选型	role_agent/architect_cli.py
工部尚书	Chief Engineer	技术分析、代码审查、策略制定	role_agent/chief_engineer_cli.py
工部侍郎	Director	代码执行、文件操作、命令运行	scripts/director/cli_thin.py
门下侍中	QA	质量审查、测试验证	Factory/Pipeline 集成
探子	Scout	只读代码探索/文档阅读 (sub-agent)	即将添加

探子角色 (Scout) - 规划中

• 定位: 并发只读访问层（sub-agent）
• 核心价值: 解决单次 LLM 上下文有限问题，支持多路并发读取
• 执行模式:
  • 探索模式 → 探索目录结构/模块
  • 搜索模式 → 搜索特定内容
  • 总结模式 → 读取并总结文件内容
• 调用方式: 由 PM/Chief Engineer/Director 按需调用
• 特点: 只做读取，不做写入；由调用者自己汇总结果

# Architect (中书令) - 交互式架构设计
python -m core.polaris_loop.role_agent.architect_cli --mode interactive --workspace .

# Chief Engineer (工部尚书) - 交互式技术分析
python -m core.polaris_loop.role_agent.chief_engineer_cli --mode interactive --workspace .

# 统一角色对话 API
curl -X POST http://127.0.0.1:49977/v2/role/{pm|architect|chief_engineer|director|qa}/chat \
  -d '{"message": "你的问题"}'

---

二、硬约束

1. 所有文本读写必须显式 UTF-8
2. 零信任：任何上游输出都不默认可信，必须二次校验
3. 禁止"声称修复但未复测"：每次修复后必须复测对应门禁
4. 禁止仅做表层补丁：必须定位根因并修复
5. 修复范围允许双域：Polaris 主仓 + C:/Temp 新项目
6. 运行策略为"直到通过"：不设轮次上限，持续循环，直到所有验收门禁 PASS
7. 只能修改 Polaris：绝对不能修改目标项目的任何代码
8. 实时推送单轨制：应用/前端实时状态只能走统一 Nats-JetStream + /v2/ws/runtime WebSocket；禁止新增或保留 SSE、HTTP 长轮询、setInterval/timer fetch 轮询、轮询兜底、文件轮询伪实时。HTTP 只允许用于初始快照、显式用户刷新、一次性命令/查询；测试代码可为等待异步完成而轮询状态端点，但不得作为产品实时链路。
9. 全链路任务流唯一制：运行态任务链路只能是 PM → Chief Engineer → Director。PM 只能生成任务合同并交给 Chief Engineer 产出蓝图/交接证据；Director 只能消费 CE 交接后的任务。禁止任何产品代码、脚本、UI 或文档回退为 PM → Director 旧链路，缺少 CE 投影/蓝图时必须显示阻塞或等待 CE，不得直连 Director。
10. 工具调用归一化优先：平台必须适配不同 LLM 的自然工具调用习惯，先通过统一 ToolSpecRegistry/tool alias/arg_aliases 归一化工具名与参数，再进入授权、路径、命令、读写门禁；禁止强迫 LLM 只按 Polaris 内部字段写调用。不可安全推断的调用必须 fail-closed 并留下工具/LLM/runtime 证据，禁止吞异常、硬编码成功、静默 fallback。
11. LLM 最终请求上下文审计：每次真实 LLM 调用都必须审计最终 provider request，而不只统计 messages 投影；审计至少包含 message/tool schema/response_format token 估算、最终请求 token、窗口利用率，以及 PM 合同、Chief Engineer 蓝图、目标文件、失败反馈、workspace quality evidence 覆盖度 flags。ContextOS 必须优先展示最终请求上下文 token，禁止用 messages-only 或 prompt usage 冒充最终上下文占用。context_snapshot_ref 只能表示已落盘、可通过 /v2/context/{hash} 读取的 24 位 hex 快照 key；request_hash、prompt_hash、call_id、turn_id、路径、审计包 hash 或旧事件字符串不得冒充 context_snapshot_ref，前端不得为非法 ref 展示“查看完整上下文”入口或发起 /v2/context/{hash} 请求。
12. 角色工具失败外部审计（主 Agent 专用，禁止产品化）：PM、Chief Engineer、Director、QA 任一角色发生工具调用失败、工具调用缺失、工具参数无法归一化、工具结果被误判成功、或 LLM 输出被错误当作工具 action 时，主 Agent 可以安排至少一个 OpenCode 外部 Agent 做独立审计。该审计只属于 Codex/Claude 等主 Agent 的工程协作手段，绝对不是 Polaris 平台能力、运行时依赖、Factory gate、bench 成功条件、ContextOS/ReceiptStore 事实源或产品功能。Polaris 产品代码、脚本、UI、runtime event、Run Ledger、bench report 不得调度、等待、要求或展示 OpenCode 审计状态作为平台证据。外部审计应覆盖最终送入 LLM 的完整 provider request 上下文、工具调用归一化链路、ToolSpec/arg_aliases、runtime event、LLM 调用日志、ContextOS 证据和失败归因；若 LLM event 因安全策略 redacted 了 messages/content，主 Agent 必须把 context_snapshot_ref 对应的 runtime/contexts/<shard>/<hash> 快照文件纳入自己的外部审计证据包；禁止把 OpenCode 审计结论写成 Polaris 的 SSoT。

• Claude CLI JSON Sub-Agent 标准（主 Agent 默认派工方式）：需要并行分配外部子任务时，主 Agent 默认使用 claude -p "<任务指令>" --dangerously-skip-permissions --output-format json --json-schema '<schema>'，而不是交互式日志或非结构化后台输出。每批最多 3 个 Sub-Agent；任务必须先按文件/目录/职责拆成互不重叠的范围，不能保证互斥时必须降级串行。Sub-Agent 任务必须显式声明 mode=audit 或 mode=implementation：audit 只读；implementation 可以直接修改授权范围内代码、测试和文档，但必须使用独立 worktree/sandbox 或共享主仓互斥文件集合，且不得跨桶写入。每个 Sub-Agent 的提示词必须包含：任务 ID、mode、允许/禁止修改范围、必须读取的规范、必须使用 codegraph/MCP 的审计要求、验证命令、输出 JSON schema、报告落盘路径（推荐 /tmp/polaris-subagent-<batch>-<id>.json）。JSON 结果至少包含 mode、status、summary、scope、files_read、files_modified、commands_run、findings、risks、next_action。主 Agent 只能把该 JSON 当作外部执行报告，必须重新检查 git status、git diff、测试结果和越界修改；禁止把 Claude/OpenCode 子任务状态或报告写入 Run Ledger、ContextOS、ReceiptStore、Factory/Bench 成功条件、产品 UI 或 runtime event。

1. 最终请求唯一真相与主动缺陷发现制：主 Agent 不能等待用户从 UI 发现问题后再被动排查。每次 bench、角色运行或工具失败后，必须主动先验 context_snapshot_ref 对应的最终 provider request，并把它作为唯一事实源；messages、prompt 文本、RoleProfile whitelist、日志摘要、UI 文案都只能作为辅助证据，不能替代最终 provider request。必须逐项比对：

• provider_request.messages[0] 的角色身份是否与当前角色一致，禁止 CE/Director/PM 系统提示串线。
• provider_request.tools 是否包含任务和提示词要求的可调用工具；如果提示词要求 repo_tree、read_file、repo_read_*、write_file、execute_command 等工具，而最终 tools schema 缺失，直接按 P0 平台缺陷处理。
• provider_request.tool_choice、response_format、tool schema 参数、arg aliases 是否与 ToolSpecRegistry/运行时归一化链路一致。
• final_request_context_audit 的 token、窗口利用率、tool schema token、coverage flags 是否来自最终请求，禁止用 messages-only 估算冒充。
• 弱模型 slim/单批次/retry/escape-hatch 策略不得把提示词要求或任务必需的读/定位工具静默裁掉；若确需限制工具，必须在 runtime event 和 ContextOS 中写出裁剪原因、原始工具集、裁剪后工具集和风险。

1. 主 Agent 自主审计闭环：遇到进展卡住、长时间停留同一项目、LLM call_error、工具调用缺失、上下文快照不可用、角色身份异常、可运行门禁失败时，主 Agent 必须立即形成机器可读缺陷清单并逐项关闭；禁止反复描述同一现象而不落地修复。每个缺陷至少记录：现象、最终请求证据、runtime/bench/log 证据、根因分类、修复文件、验证命令、剩余风险。未完成该闭环不得宣称“继续跑下一批”或“已验证模型能力”。
2. 多维主动审计矩阵：主 Agent 不能只沿当前报错点线性排查，也不能只修用户指出的单点。每次卡住、重跑、失败归因或进入下一项目之前，必须主动从以下维度并行找缺口，并把结论写入阶段报告：

• 架构链路：是否仍有旧链路、旁路、fallback、PM→Director、跳过 CE、双轨实时或目标项目污染。
• 角色身份：PM/Chief Engineer/Director/QA 的 system prompt、role metadata、run_id、trace_id 是否串线。
• 最终 LLM 请求：provider request 的 messages/tools/tool_choice/response_format/token/window/coverage 是否合理。
• 工具链路：ToolSpecRegistry、tool alias、arg_aliases、parser、native tool、text fallback、授权、路径门禁、结果判定是否一致。
• 上下文卫生：长期 retry 回灌、过期失败原因、无关历史、矛盾指令、弱模型过载、messages-only 统计冒充最终请求。
• 运行时事件：Nats/JetStream、/v2/ws/runtime、runtime event、bench session、ContextOS、日志、截图或测试结果是否互相印证。
• UI 投影：前端是否接收到真实推送，workspace/阶段/进行中/工具调用/ContextOS 快照是否与后端状态一致。
• 产物门禁：落盘、依赖/环境、build/test/lint 至少一个真实门禁、CLI/Web/API 至少一个入口是否实际执行。
• 模型健康：绑定模型是否可达、连续失败是否应跳过、超时是否匹配模型速度、弱/强模型策略是否按配置生效。
• 收敛性：当前问题是否是新通用根因，是否需要平台硬化、文档沉淀、回归测试和下一批验证。

1. 用户观察反向触发复盘：凡是用户通过 UI、截图、日志或手工观察先于主 Agent 发现缺陷，必须视为主 Agent 审计遗漏。修复时除解决代码根因外，还必须补充一条可自动发现同类问题的审计规则、测试、日志断言或文档硬约束；禁止只修当前样例。
2. Bench 测试态边界（强制）：任何 Bench、Factory Bench、factory_bench、L1-L12 bench、benchmark harness、压力测试 UI/API/脚本都只允许存在于 Polaris 内部测试/开发/审计模式，用于压测平台能力、暴露通用根因和生成审计证据。Bench 不是正式项目功能、不是生产工作台、不是用户交付体验、不是控制面事实源；正式环境/生产环境不得出现 Bench 入口、Bench 文案、Bench 专属 UI、Bench 专属状态模型或以 Bench 命名的业务 API。平台基础设施能力（如 Run Ledger、Job Token、ContextOS、ReceiptStore、Verifier/Gate Policy）必须以平台级命名和契约沉淀，Bench 只能在内部测试态作为这些平台能力的生产者/消费者之一。禁止把为 Bench 写的临时字段、视图、路由或运行假设上升为生产语义；需要在正式产品展示时必须接入平台级 projection/API，而不是 benchService、bench session 或 factory audit 文件。Browser、视觉、多模态 QA、用户脚本、领域脚本等 verifier modality 是平台 Control Plane 可选能力，默认关闭；只有当前环境显式声明可用时才允许设为 hard-required evidence，禁止由 Bench 或内部测试状态决定正式项目必须启用这些能力。Job Token 是从控制面事实源派生的 capability token，不得成为第二事实源；正式写入和命令工具执行层必须消费 Job Token 派生 scope，并把 token/hash/stage/project evidence 写入 effect receipt。
3. 多实例总控与项目观测（强制）：Polaris 仍保持“单个后端进程绑定单个 workspace”的运行时不变量；多项目并行观测必须通过平台级 Instance Registry + Launcher 总控实现，即多个独立实例共享同一个 polaris_root、各自拥有独立 workspace / runtime_root / backend port / frontend port。禁止把 settings.workspace、ContextOS、TaskBoard、Run Ledger 或前端全局状态改造成临时多租户拼接层；需要切换/观测多个项目时，启动多个 Polaris 实例或使用 /launcher 总控打开对应实例页面。实例工作台入口必须携带显式 instance / backend / token / workspace 绑定（URL query 或 VITE_POLARIS_* 环境变量），前端 API 与 /v2/ws/runtime 连接必须消费该 workspace 绑定；禁止打开实例页面后静默回退到默认 backend、默认 workspace 或主仓 runtime。任何由 Agent、CLI 或内部压力工具启动且需要被观测的实例，都必须通过 polaris.cells.instances / /v2/instances / python -m polaris.delivery.cli.backend serve --register-instance ... 写入 Instance Registry；注册写入只能作为发现/运维视图，不得替代 PM、Chief Engineer、Director、QA、ContextOS、ReceiptStore 或 Run Ledger 的事实源。Launcher 实时更新只允许走 runtime.v2 WebSocket status.instances 事件，禁止用 HTTP polling 模拟实例状态。factory_bench 只能在内部测试态把项目注册为 kind=bench_project，便于总控观测；共享后端的 bench 注册只能视为“可观测的测试实例”，不能冒充独立生产实例，不得把 Bench 语义提升为生产项目模型。详细规则见 src/backend/docs/MULTI_INSTANCE_LAUNCHER.md。
4. ContextOS 快照可读闭环（强制）：LLM 事件中暴露给 UI 的 context_snapshot_ref 必须是 /v2/context/{hash} 和 /v2/context/{hash}/final-request 在同一 workspace 绑定下可读取的 24 位 hex key；禁止把 request_hash、prompt_hash、call_id、turn_id、路径字符串或旧事件 id 当作完整上下文引用。Context 快照读取必须以请求 workspace 为硬边界，并按平台级候选链查找：当前 resolve_storage_roots(workspace).runtime_root、Instance Registry 中同 workspace 的 runtime_root、默认 KernelOne system cache；禁止只查 active runtime root 后就向 UI 宣称快照丢失。404 必须返回 context_hash、workspace 和 searched_paths，前端必须展示这些证据；如果事件来自其他 workspace，前端 runtime guard 必须先丢弃，不能把跨项目 hash 送入当前 ContextOS modal。/v2/context/* 属于本地开发观测关键路径，loopback 读取不得被普通 API rate limit 误伤，远程访问仍必须限流。
5. Bench 全局观察器显式授权（强制）：event.bench 是内部测试态 workspace-agnostic 事件流，只能由总控/主开发页在显式 globalObserver 或等价平台开关下订阅；从 Launcher 打开的具体实例页、PM/CE/Director/QA/ContextOS 项目工作台不得默认订阅全局 bench、不得被 “newest bench session” 静默切换 workspace。前端组件如 BenchStatusStrip、BenchPanel 必须默认只渲染调用方传入的 scoped bench 数据；没有显式全局授权时不得自行调用 useFactoryBench({autoSelect:"newest"})。任何新增 bench 观测 UI 都必须有测试证明 enabled 本身不会触发全局订阅，只有显式全局观察模式才会订阅。
6. Observed Bench 独立化启动（强制）：Instance Registry 中带有 metadata.backend_binding=shared_backend_workspace_switch 的 bench_project 只是共享后端观测记录；当用户或 Agent 从 Launcher/API 对它执行 restart/独立启动时，Supervisor 必须分配新的 backend/frontend 端口并启动独立实例，禁止复用共享 backend 端口或把 observed 记录伪装为 running。
7. factory_bench 并行实例模式（强制）：多个 Agent 并行跑 factory_bench 不得共享同一个 49977 backend 做 workspace switch；runner 默认必须使用 isolated，让每个项目先启动独立 Polaris backend/frontend，再把该项目的 Factory run 发到自己的 backend。--launcher-instance-mode observed / FACTORY_BENCH_LAUNCHER_INSTANCE_MODE=observed 只允许显式用于轻量观测和串行兼容测试。
8. 主端口预留与 workspace 隔离（强制）：49977/5173 只属于 main 开发实例。任何 bench_project、Factory Bench、临时项目实例或 Agent 私有项目后端不得直接使用 python -m polaris.delivery.cli.backend serve --port 49977，不得把 bench workspace 通过 POST /settings 写入主后端，且不得通过手工端口复用把主 Web 前端导向测试项目。项目实例必须走 Instance Supervisor/Launcher 自动分配端口；Supervisor 必须忽略或重分配 bench 对 49977/5173 的显式请求，禁止抢占或复活主端口。多 Agent/bench 观测阶段 main 后端默认不得启用 --reload，否则其他 Agent 修改 src/backend 会触发 reload 风暴并造成前端 API/WS 短时超时；只有单人调试后端热重载时才允许显式启用。若发现 lsof -i :49977 的进程 workspace 不是主仓，必须只清理该错误进程并恢复 main 实例，不得误杀其他 Agent 的独立实例端口。
9. Launcher 自管理边界（强制）：当前承载 Launcher API 的后端实例不得通过自己的 /v2/instances/{id}/stop|restart|delete 自我停止、自我重启或删除自身 registry 记录；这类操作必须 fail-closed，避免控制面先杀掉自己后无法完成重启/清理。前端必须禁用当前控制实例的 stop/restart/delete，仅允许管理其它独立项目实例；清理 stale bench 只能作用于 kind=bench_project、非 running、backend dead 且 metadata.internal_test_only=true 的内部测试实例。
10. Run Ledger evidence 语义（强制）：平台级 Run Ledger 投影必须区分“缺少 required evidence”和“required evidence 已存在但失败”。evidence_policy.missing_required_modalities 只表示控制面/工具层没有产出该类证据，例如没有命令收据；evidence_policy.failed_required_modalities 表示证据真实存在但门禁失败，例如 npm test、go test、browser smoke 或用户脚本返回失败。UI、ContextOS、QA、Factory 内部测试和主 Agent 审计不得把 failed evidence 继续渲染成 missing evidence；前者是产物/验收失败，后者才是账本或工具链漏记账。任何 resolved/pass 状态都必须同时满足：无缺失 required evidence、无失败 required evidence、门禁 exit code/receipt/hash 证据闭环。
11. Director deterministic repairs 收敛边界（强制）：确定性修复内核唯一归属 director.runtime。src/backend/polaris/cells/director/runtime/internal/repair_kernel/ 是 Cell 私有实现；跨 Cell 只能通过 polaris.cells.director.runtime.public 或 polaris.cells.director.runtime.public.service 消费。public repair 执行入口只能是通用 PlanDirectorRepairCommandV1 / RunDirectorRepairCommandV1 + plan_director_repair / run_director_repair；禁止新增 plan_director_<language>_*、run_director_<language>_* 或按规则命名的 public facade。语言/规则分派必须留在 runtime internal dispatcher/registry 后面。roles.adapters/internal/director/deterministic_repairs/ 只允许作为迁移期 legacy strategy host，不得重新拥有 repair kernel、strategy catalog、policy gate、receipt contract、PatchComposer、scheduler、shadow comparison 或 AGI advisory contract。禁止恢复 roles/adapters/internal/director/repair_kernel/**，禁止恢复 deterministic_repairs/strategy_catalog.py 作为事实源，禁止 roles.adapters 直接 import polaris.cells.director.runtime.internal.repair_kernel。execute_method.py 若需要 repair catalog、summary、planning、coverage、shadow comparison 或 advisory policy，只能走 director.runtime.public.service；legacy tool_results 投影为 repair_kernel summary 必须使用 ProjectDirectorRepairKernelSummaryV1 + project_director_repair_kernel_summary，build_director_repair_kernel_summary 只保留在 runtime public 兼容层和测试中，roles.adapters 不得调用；post-execution 语言修复只能通过 roles.adapters/internal/director/post_execution_repair_bridge.py 的统一入口，step 调度事实源必须来自 query_director_repair_post_execution_schedule，bridge 只允许保存 step_id -> runner 绑定，且 runner key 集合必须与 runtime schedule 完全一致，禁止在 adapter 里重新定义 phase/priority/depends_on 目录；禁止在 execute_method.py、Factory、QA 或 bench harness 里直接 import 具体语言 repair 函数。新增 deterministic repair 必须遵循 Diagnostic -> Plan -> Compose -> Policy/Execute -> Receipt -> Revalidate，planner/composer 不得直接写文件；commit 副作用必须经由 Director policy-gated 工具适配器执行，精确 text_replace 优先走 edit_file，整文件生成、结构化序列化、fallback 或 rollback 才允许走 write_file，并产出 before/after hash receipt；多轮执行必须通过 repair kernel scheduler 建模 priority、depends_on、round_number、max_rounds 和 cycle breaker。Receipt 必须能绑定 post-check evidence，至少包含 verifier command、exit code、before/after diagnostics、resolved/residual diagnostic ids、errors_before/errors_after/net_error_reduction。未来 AGI/Resident 只能作为 non-authoritative advisory：不得写文件、生成 authoritative plan、覆盖 policy、给 success verdict、注册规则、成为 Run Ledger/ReceiptStore/ContextOS 事实源；任何 suggested-rule payload 必须先通过 validate_director_repair_advisory，该入口只读、只标准化或拒绝建议，不产出 repair plan 或注册规则；validation summary 也必须显式投影 agi_execution_authority=false、writes_allowed=false、registration_allowed=false、authoritative_receipts_allowed=false、suggested_rules_are_advisory_only=true。

• 当前 runtime executable binding 口径以 runtime_repair_bindings() 为唯一事实源；禁止在 AGENTS/CLAUDE/README 手写 source_tool 固定总数或长列表作为事实源；需要精确数量或列表时运行 runtime_repair_bindings() 或查询 query_director_repair_strategy_catalog，Rust executable 关键不变量为 20 个。Rust module-file topology 规则 E0583 / E0761 已分别通过 deterministic_rust_missing_module_file_repair / deterministic_rust_duplicate_module_file_repair 成为 runtime executable；Rust missing lib target、lib root facade、struct literal missing field 也已拆成明确 source_tool；后续 Agent 不得把这些规则重新接回 legacy direct-write helper；所有 runtime binding source_tool 必须通过 RunDirectorRepairCommandV1(source_tool="<runtime binding source_tool>") 执行，禁止新增语言/规则专用 public facade。
• deterministic_rust_post_repair 只是 aggregate post-execution callback / legacy schedule label，不是 runtime_repair_bindings() 暴露的 executable_runtime source_tool，不得传给 PlanDirectorRepairCommandV1 / RunDirectorRepairCommandV1。Runtime schedule 的每个 step 都会投影 source_tool_kind 与 executable_runtime_source_tool；任何 schedule consumer 必须以这两个字段为准，只有 source_tool_kind="executable_runtime" 且 executable_runtime_source_tool=true 的 source_tool 才能作为 public Plan/Run source_tool。delete_file 已作为 repair kernel operation/tool 能力存在并有 receipt/policy 语义；但不能因 delete_file operation/tool 存在就恢复 aggregate Rust topology repair。Rust post aggregate 不得作为可执行绑定恢复；新增或迁移余量仍需 coverage、policy 和 revalidation evidence 后才能拆成明确 source_tool。
• Targeted gate 同步：最新 targeted gate 摘要为 842 passed（2026-06-26 docs/metrics sync 口径引用）；后续调整 binding/gate 文档时必须同步更新该摘要或命令证据。
• PlanDirectorRepairCommandV1 / RunDirectorRepairCommandV1 只能接受 runtime_repair_bindings() 暴露的 executable_runtime source_tool。未知、未注册、reserved_only 或仅 metadata_rule_registered 的 source_tool 必须 fail-closed，并在 public planning/run result 的一等 error_code 返回 unsupported_repair_source_tool；不得写 workspace，不得静默 fallback 到 legacy regex/direct-write helper，也不得由 adapter/bench/QA 自行补救执行。
• materialization-quality 修复也必须通过 runtime schedule：roles.adapters/internal/director/materialization_quality_repair_bridge.py 只能消费 run_director_materialization_quality_repair_schedule，并只绑定 runtime 声明的 step_id；runner key 集合必须与 runtime-owned schedule 完全一致，禁止在 adapter 里新增、删除或重排 schedule step，禁止在 adapter 里重新定义该阶段 phase/priority/depends_on。当前 materialization schedule 已拆成 materialization.hygiene_scaffold、materialization.typescript_scaffold、materialization.typescript_compiler、materialization.html_entrypoint、materialization.node_manifest、materialization.rust_compiler、materialization.target_runtime、materialization.python_import、materialization.go_import 九个 runtime-owned step；这些 materialization step 的 source_tool_kind 默认为 callback_schedule_label，不得把它们当作 RunDirectorRepairCommandV1 的 executable source_tool。禁止恢复单个 materialization.quality_repair_host 大步骤。旧 _apply_deterministic_materialization_quality_repairs facade 已硬切删除，禁止恢复、转发或作为测试/bench/Agent 入口。

1. Repair coverage 先于补规则（强制）：遇到新的 compiler/verifier diagnostic，不得先在 legacy deterministic function 里临时补 regex。必须先通过 director.runtime.public.service.query_director_repair_coverage 或 internal registry 形成 coverage report；known_rule_matched=false 是可审计平台缺口，必须记录 diagnostic code/path/message/archetype/phase 建议后再决定是否新增规则。Coverage report 是只读发现层，禁止写文件、禁止隐式自动注册新 source_tool、禁止让 AGI suggested rule 直接成为 authoritative rule。未来更多编程/脚本语言的专项修复由后续 Agent 通过 L1-L12/九十多个项目 bench 证据逐步补齐；开工前必须先查 query_director_repair_language_slots，优先复用已有 reserved slot（例如 Vue/Svelte、Scala/Groovy、Elixir/Erlang、Haskell/OCaml/F#、Zig/Nim/Crystal、Perl/PowerShell/Julia、Objective-C/MATLAB/Fortran/Terraform、Dockerfile/Make/Bazel/Starlark、YAML/JSON/TOML/Nix、GraphQL/Proto/Solidity/Vyper 等），没有槽位才在 director.runtime registry 中补 reserved slot。slot 的 implementation_status 必须按三态理解：reserved_only 只表示预留扩展落点，metadata_rule_registered 只表示 catalog/coverage 已有规则元数据，只有 executable_runtime 才允许通过 RunDirectorRepairCommandV1 执行。新增语言规则必须先落 catalog/archetype/coverage/receipt/verifier evidence，再接入 legacy bridge 或 runtime scheduler，禁止为单个样例直接扩写 execute_method.py 分支。迁移旧策略时必须先暗跑：通过 compare_director_repair_shadow_run 对账 legacy tool_results 与新 kernel receipt 的 files/source_tools，matched 后才能切断旧路径；shadow comparison 只读、不得写 workspace。CompareDirectorRepairShadowRunV1.comparison_mode 必须显式区分 independent_shadow_run 与 legacy_projection_self_check；只有 independent_shadow_run 且 scope/hash/revalidation/authoritative receipts 全部满足时才允许 cutover_ready=true。legacy summary projection 内嵌的 dark_launch_comparison 只是 legacy_projection_self_check，必须保持 cutover_ready=false 和 independent_shadow_required blocker，不能作为切断旧路径的证据。