PR ！32 已于 2026-10-29 17:05 被合入（merged_by: sunfei2021）。因该仓 PR 合入后关闭评论通道（405），评审讨论内容迁移到本 issue，供大家讨论后续处理。

讨论稿（事后评论）：评审期间本 PR 已被合入（2026-10-29 17:05），本评论不含合入结论，转为后续工作的讨论基础。两个断点均已核实为真实的公共层缺口；意见分两类——①两条约束的分层归属（是否上浮公共层）；②无论落点在哪层都建议修改的 4 点（可当作后续 PR 的修改清单）。

断点核实（对照公共层现状）

修复方向正确，checklist 措辞也精确（点名了三份文件名）。以下两类意见供讨论。

第一类：分层归属——放 profile 还是公共层（讨论项）

• 两条约束的内容与 appfwk 领域无关：任何目标仓都有 Agent 指南编码规则，任何领域的 Implementer 都可能自建 evidence 顶门禁；领域味道只出现在示例（ability_runtime/AGENTS.md#6. 编码规则）。
• 失败域 ≠ profile 生效域：放进 appfwk profile 后只有 appfwk 执行受保护；arkweb/arkui/arkdata/arkgraphic 与无 profile 执行同样会复发这两个断点。
• 机制事实：7 个能力 skill 中 ohos-implement 是唯一不加载 profile 的。「Implement 衔接约束」段实际在 Plan/Review/Validate 门禁被消费，靠 Plan 阶段把禁止项写进 execution-plan 间接传导到 Implement——能用，但比公共层落点多一跳。
• 候选路径：
  • A. 先合 profile 止血 + 开 issue 上浮公共层：公共层落点 = execution-plan.md 模板禁止项固定一行 + ohos-implement 反模式表两行 + ohos-plan 补一条 Read-only Context 指引；上浮后删除 profile 内条目（沿用 ！20 → issue #9 的处理模式）。
  • B. 直接改公共层：一次到位、所有领域受益；但涉及模板契约 + 2 个 skill + 验证链 + marketplace 发版，成本与周期更高。
• 现状：本 PR 已合入，A 的前半步（profile 止血）事实上已发生。请大家定夺：是否开「上浮公共层」issue（建议分配给本 PR 作者）；第二类 4 点随上浮 PR 还是单独小 PR 修。

第二类：无论在哪层合入，都建议先修改的 4 点

1. 「必须引用目标仓根 AGENTS.md 编码规则章节」是无条件要求（Phase 4 行 / 代码质量重点 / 使用规则三处均如此）：目标仓没有 AGENTS.md 或没有编码规则章节时该条无法满足。建议改为条件式——存在该章节时必须引用；不存在时记录 N/A + 已确认的替代规范来源。同时建议把「目标仓根 AGENTS.md」放宽为「目标仓 Agent 指南（AGENTS.md/CLAUDE.md）」，与本 profile 上下文来源表及 gate-checklist.md 措辞对齐。
2. 段名与消费时机错位（### Implement 衔接约束）：没有任何 skill 在 Implement 阶段加载 profile（ohos-implement 不读）。建议段内加一句传导说明（本段在 Plan 门禁核对、经 execution-plan 禁止项传导至 Implement），或改名「Plan→Implement 衔接约束」。若上浮公共层，同一条同样适用：落点应在 ohos-implement 反模式表（implement 时刻真正被读到），而不是只在 plan/review 侧声明。
3. 三处近逐字重复：Phase 4 单元格现在约 160 字、两条完整政策句，与「Implement 衔接约束」段、「使用规则」段重复同一内容。建议一处定义（专项清单段）、他处要点引用；后续无论上浮还是保留，重复越少维护成本越低。
4. 「禁止项必须声明」与模板语义错配：execution-plan.md 模板的「禁止项」是“不得出现以下内容”的负面清单，而新要求是“必须声明一条红线”（声明式）。建议明确落点表述：公共层方案可直接在模板禁止项清单中固定一行；profile 方案建议表述为「禁止项清单后附加固定声明」，避免“在负面清单里写必须句”产生执行歧义。

第二类 4 条都不阻塞分层讨论，可随本 PR 或上浮 PR 一并处理。