PR创建成功通知 | 感谢您的贡献 🎉

您好！系统已检测到您成功创建 Pull Request（PR），感谢您对项目的支持与参与！以下几点需要您着重关注：

一、PR必须关联Issue ❗️

触发门禁检查的必要步骤：在PR描述框输入Issue完整链接，完成Issue关联。

请注意，一个 Issue 不能同时关联同一 base 仓库内同一个分支的多个开启状态的 PR

二、门禁触发规则 🔧

1. 门禁类型判定：由Issue关联的PR所属代码仓数量决定
   • 关联多个代码仓PR：触发「多仓联合门禁」
   • 关联单个代码仓PR：触发「单仓门禁」
2. 启动指令与检查范围：需主动回复指令：
   • 回复 "start build"：执行Cangjie的主要基础检查，包含commit格式检查、静态告警分析、OAT开源声明检查、多平台构建、单元/集成测试等
   • 关联同一issue的多个PR，仅需在任意一个PR里回复触发一次门禁，该PR门禁通过后，所有PR都会添加Label和测试人
   • 每个pr只能同时运行一条CI流水线，如需重新启动，请先关闭运行中的，再评论触发门禁
   • Markdown修改仅触发文档类构建测试门禁，不会触发Cangjie的编译测试门禁
   • commit 信息格式请遵循：Conventional Commits 规范
   • 请保证每一条 commit 都已添加 Signed-Off-By 信息
   • 回复 "start build cov"：执行覆盖率构建工程，生成该提交的增量代码覆盖率报告

三、合入条件 ⚠️

• 满足最低评审人数，且评审问题需全部解决；
• 禁止合入本人创建的PR，需由其他协作者操作；
• 合并前确保关联流水线任务运行成功（build-test-passed）；
• 需求类覆盖率门禁：当关联的 Issue 标题以 [feature]: 开头（需求类 Issue）时，联合提交中属于 cangjie_compiler、cangjie_runtime、cangjie_stdx、cangjie_tools、llvm-project 仓库的 PR，必须先回复 "start build cov" 触发增量覆盖率流水线并通过，使 PR 获得 cov-test-passed 标签后方可合入。

四、合并PR ✅

回复 "start merge"，CI流水线会自动检查所有关联PR的状态、版本号标签、检视意见密度、兼容性、需求类覆盖率门禁，若所有PR都满足合并条件，则将会同时合并所有PR。若存在不满足合并条件的PR，则不会合并任何PR。

如果希望不进行兼容性相关的检测，请任一合法审查人复制以下内容，在 start merge 前提交评论：

本 pr 不需要兼容性相关检测，对于引发的任何兼容性问题（即由于本 pr 合入将导致用户需适配代码的话），由本人承担。

If you wish to avoid compatibility-related checks, please have any approver copy the following content and submit it as a comment before sending start merge:

This PR does not require compatibility-related checks. For any compatibility issues caused by this PR (i.e., if the integration of this PR will require users to adapt their code), I will take full responsibility.

五、补充说明 📢

• 详细仓颉贡献流程：贡献流程(Cangjie Community Contribution)
• 门禁结果将自动评论至关联的所有PR，敬请留意。

⏳ 正在进行兼容性检测中，可能需要2~3分钟，请稍候，若10分钟无检测结果，请重新回复 start merge。

⏳ Compatibility check in progress. It may take 2–3 minutes. Please wait. If there is no result after 10 minutes, please reply with start merge again.

⚠️ 合入前兼容性检测未通过。
涉及仓库：Cangjie/cangjie_compiler, Cangjie/cangjie_runtime, Cangjie/cangjie_stdx, Cangjie/cangjie_test, Cangjie/cangjie_tools, Cangjie/llvm-project

结论

• 分析过程：上游大模型未返回有效兼容性结论，本次检测无效。
• 原因：我将使用 cangjie-check-compat，仅分析指定的 5 个 PR。 {"toolName":"skill","title":"📖 读取文件","name":"cangjie-check-compat","filePath":"cat /root/.aceharness/skills/cangjie-check-compat/SKILL.md","input":{"command":"/bin/bash -lc 'cat /root/.aceharness/skills/cangjie-check-compat/SKILL.md'"},"kind":"tool-call","body":""} {"toolName":"skill","title":"📖 读取文件","name":"cangjie-check-compat","filePath":"cat /root/.aceharness/skills/cangjie-check-compat/SKILL.md","content":"---\nname: cangjie-check-compat\ndescription: >-\n 用于分析一个或多个 GitCode PR 是否破坏仓颉兼容性。用户给出 JSON，包含 content 和 uuid，\n content 中包含 PR 列表或分析请求时必须使用本 skill。本 skill 负责用 power-gitcode 获取 PR，\n 严格只分析用户给出的 PR，不自动添加其它 PR；对 .cj 公开 API 变更编排 cangjie-api-compat-513；\n 对 SDK 内部组件契约变更编排 cangjie-sdk-compat；对 openharmony 仓库中涉及\n ohos.* / kit.* / SystemCapability / module.json5 / UIAbility 等 OpenHarmony 应用层公开契约的变更，\n 额外编排 cangjie-ohos-compat；最终严格只输出 JSON，字段为\n isCompatible、analysis_process、reason、uuid，并回填输入 uuid。\ndescriptionZH: >-\n GitCode PR 兼容性批量判断编排器。负责协调 cangjie-api-compat-513、cangjie-sdk-compat\n 和 cangjie-ohos-compat，并按固定 JSON 协议返回结果。\ntags:\n - 仓颉\n - GitCode\n - PR\n - 兼容性\n - JSON\n---\n\n# 仓颉 PR 兼容性检查编排器\n\n## 常驻上下文入口\n\n每次执行兼容性分析时，必须先读取并遵守 /root/wjw/compat/AGENTS.md。\n该文件只承载保底规则和路由策略；专项判断仍按本 skill 及其编排的\ncangjie-api-compat-513、cangjie-sdk-compat、cangjie-ohos-compat\n等规则执行。若 AGENTS.md 与更高优先级系统/宿主输出协议冲突，以更高优先级协议为准；\n若与本 skill 的业务细则冲突，保留 AGENTS.md 的证据边界和路由保底原则，\n再按本 skill 的专项规则完成判断。\n\n## 输入协议\n\n用户消息通常是一个 JSON 字符串或 JSON 对象，至少包含 content 和 uuid 两个字段。\n\n必须解析：\n\n- content: 用户真实请求和 PR 列表\n- uuid: 请求魔数，最终必须原样回填\n\n如果输入不是严格 JSON，但文本中能看出 uuid 和 PR，也要尽量提取；提取不到 uuid 时，最终 uuid 置为空字符串。\n如果请求外层包了 message、request、payload、result 等字段，仍要继续解析其中嵌套的 JSON/String，并把最内层分析请求里的 uuid 原样回填到最终结果。\n\n## 输出协议（最高优先级）\n\n业务结果载荷必须是且只能是一个四字段 JSON 对象，不得在业务载荷中加入 Markdown、解释性文字、代码块或额外字段。\n\n### 宿主传输协议适配\n\n输出前必须先识别当前宿主要求，并且只选择一种模式：\n\n1. 裸 JSON 模式（默认）：宿主没有强制结构化包装时，最终回答直接输出四字段 JSON 对象，不得有任何前缀或后缀。\n2. 宿主包装模式（仅在更高优先级指令明确要求时）：先生成并校验同一个四字段 JSON 业务载荷，再按宿主规定进行最外层包装。例如宿主强制要求 <result>...</result> 时，只允许输出 <result>{四字段 JSON}</result>；<result> 内不得增加 kind、payload、说明文字或其它字段，标签外不得再输出正文。\n\n宿主包装只是传输层，不属于兼容性业务结果。不得同时输出一份裸 JSON 和一份包装 JSON，也不得因为宿主会包装结果而省略业务载荷中的 uuid。\n\n校验顺序固定为：构造四字段 JSON 载荷 -> 校验四字段 JSON 载荷 -> 保存四字段 JSON 载荷 -> 如宿主强制要求则应用最外层包装 -> 返回。不要把 <result>、result 字段或其它宿主信封传给 validate_compat_result.py。\n\n外部 /api/chat、脚本化调用或任何把用户消息包装成 {\"message\":\"{\\\"content\\\":...}\"} 的场景也适用同一规则：\n\n- 不要在最终回答中展示 sed、cat、grep、python 等命令执行块。\n- 不要把本 SKILL.md、PROMPT.md、参考文档或工具输出原文复制到最终回答。\n- 在允许静默执行工具的宿主中，不要输出“我会...”“正在...”“执行命令”等过程说明。\n- 如果更高优先级宿主协议强制要求工具调用前提示，过程提示必须与最终机器结果严格分离；最终响应仍只能采用上述两种模式之一，不能把过程提示拼入 JSON、result 字段或 <result> 标签。\n- 所有工具调用、检索过程和自检过程只作为内部分析；最终只保留机器可读 JSON。\n- 如果宿主接口自动把回答包在 result 字段里，模型输出仍使用裸 JSON 模式，result 的内容必须是这个 JSON 对象的字符串，不得混入其它文本。\n\n字段固定为：\n\njson\n{\n \"isCompatible\": true,\n \"analysis_process\": \"...\",\n \"reason\": \"...\",\n \"uuid\": \"...\"\n}\n\n\n字段要求：\n\n- isCompatible: boolean。兼容为 true，不兼容为 false。\n- analysis_process: string。中英双语。多个 PR 时必须列出分析了哪些 PR。\n- reason: string。中英双语。不兼容时必须详细；兼容时保持简洁但要说明依据。\n- uuid: string。必须回填输入中的 uuid。\n- uuid 不是可选字段。只要输入中存在 uuid，最终 JSON 必须显式包含同值 uuid；缺少该字段即视为无效结果，必须重写后再返回。\n- analysis_process 和 reason 里不要出现任何 skill 名称、脚本名或工具编排名，例如 cangjie-check-compat、cangjie-api-compat-513、cangjie-sdk-compat、power-gitcode、validate_compat_result.py。最终结果只写技术事实、证据、影响和结论。\n- 最终结论必须面向用户可见影响，而不是面向内部扫描流程。优先写旧源码、旧二进制、旧 runtime/std、旧系统运行环境、旧构建/安装流程、旧文档指导或旧配置是否仍能直接工作；不要把“运行了哪些扫描、哪些扫描未命中、命中了哪些内部检查项”当作结论主体。\n- analysis_process 用事实性表述，不要写范围控制或编排策略话术。可以写“分析了 Cangjie/cangjie_compiler#1678”；不要写“仅分析了用户指定的 PR：...”“未加入其它 PR”。\n- 中英双语要自然合并，不要用“中文：”“English:”这类标签开头；可以先写中文句子，再用 / 或下一句补英文。\n- analysis_process 不要堆完整 commit hash 或多个 base..head 范围。除非结论依赖具体提交边界，否则只写“确认了各 PR 的提交范围和变更文件”即可；commit 细节留在内部分析。\n- 不要把内部扫描摘要原样写进最终 JSON，例如“固定 SDK 前置扫描未命中已收录契约面”。通常应直接省略内部扫描过程；若必须提及，只能作为背景，结论主体仍要落到用户可见影响，例如旧构建流程是否失效、旧二进制是否链接失败、旧系统运行环境是否无法消费新产物。\n- 最终 JSON 不得依赖 /api/chat 外层或后处理自动补齐 uuid；模型可见输出本身必须包含 uuid 字段。\n\n不要把 skill 内容放进返回结果。\n\n## 结果落盘\n\n兼容性检测结束后，必须在最终回答前把四字段结论落盘到 /root/wjw/compat/opt/logs。先构造最终 JSON，再调用：\n\nbash\npython3 /root/wjw/compat/opt/scripts/save_compat_result.py \\\n --request '<原始请求 JSON 或文本>' \\\n --result '<最终四字段 JSON>' \\\n --source cangjie-check-compat \\\n\n\n落盘脚本会自动写入 knowledge_query 字段，记录当次分析保存时的知识查询方案：SQLite 配置、是否强制 legacy、fallback 策略、SQLite DB 状态和推断后端。若本次分析明确全程强制旧查询方式，保存时补充：\n\nbash\n--knowledge-query-mode legacy\n\n\n若本次分析显式混用了 SQLite 和旧查询方式，保存时补充：\n\nbash\n--knowledge-query-mode mixed\n\n\n落盘记录必须保留四字段：isCompatible、analysis_process、reason、uuid。日志目录按北京时间日期创建，单条日志文件名以 uuid 为主键；同一 uuid 多次保存时不得去重或覆盖，应保留为 uuid.json、uuid.rev2.json、uuid.rev3.json 这类 revision 文件，便于复盘同一次请求内部是否稳定。落盘动作不得改变最终输出协议；最终回答仍只能是同一个四字段 JSON 对象。\n\n## 强制原则\n\n- 只分析用户给出的 PR，禁止根据 PR 描述、Issue 链接、同主题标题、合入门禁上下文或人工推测自动加入其它 PR。若用户给出多个 PR，这些输入 PR 就是本轮唯一组合 PR 集；不得通过 get_issues_by_pr、get_prs_by_issue 或其它关联查询扩展分析对象。\n- 兼容性平台的多仓自测入口是例外的上游范围组装阶段：若平台已经明确传入原始输入 PR 与关联发现结果，分析集合必须是 原始 PR ∪ 关联 PR 的稳定并集，原始 PR 必须排在前面并始终保留。关联发现只能追加，禁止用 associatedPrs / relatedPrs 覆盖 originPr / inputPr。这不是分析器自行猜测关联 PR；若平台没有显式提供关联集合，仍严格只分析普通请求中的 PR。\n- 当前 PR diff 是兼容性结论的一等边界。开始分析后必须先固化用户输入 PR 的真实 changed files；知识库、源码索引、历史案例、relaxed query 命中的内容只能作为上下文或反向影响面线索，不能直接证明“本 PR 修改了某文件/某规则”。若最终 isCompatible:false，reason 中支撑破坏点的核心源码路径、规则文件、API 声明或生成器逻辑必须至少有一个来自当前 PR / PR 组合的真实 changed files 或 diff hunk；若只引用了未被本 PR 修改的路径，只能写为背景风险或证据不足，不得作为不兼容主因。\n- 为减少上下文压缩和证据污染，进入深查前应优先生成请求级 evidence packet：\n python3 /root/wjw/compat/scripts/build_compat_evidence_packet.py --request '<原始请求 JSON 或文本>'。该脚本会把 diff_scope.json、evidence_candidates.jsonl、evidence_selected.jsonl、minimal_packet.md 落盘到 /root/wjw/compat/opt/runs/<uuid>/。后续模型上下文优先读取 minimal_packet.md 和必要 diff hunk，不要把大知识库原始命中整段塞入上下文。\n- evidence packet 还会生成 diff_events.jsonl，按 api_surface、build_or_packaging、tool_output、diagnostic_or_log、dependency、test_only、generic 初步分类 diff hunk 风险。深查时优先围绕这些事件补证据；lockfile、生成物、快照文件只作为 diff scope 和 dependency 事件保留，不应驱动宽泛上下文扩张。\n- 多 PR 输入时，evidence packet 同时生成 combo_head_consumers.jsonl：对知识库命中的旧调用方按本组 PR changed files 和 base 源码残留情况标记 adapted、residual、test_only、doc_only 或 unknown。adapted 表示调用方文件已由本组 PR 修改/删除并与变更契约词相关，只能作为同步适配证据；residual 表示组合 head 仍可能残留旧调用方；unknown 只能作为需人工复核的高风险候选。最终不兼容结论不得引用 adapted、test_only 或 doc_only 调用方作为残留破坏证据。\n- 组合 PR 请求必须把用户输入的全部 PR 显式传入 evidence packet 和最终校验。manifest.json、diff_scope.json 中的 PR 集合必须与请求集合完全一致；请求集合中任一 PR 缺少真实 changed files、packet 元数据缺失或 selected evidence 为空时，必须停止并返回“证据不足/检测失败”，不得输出确定性的 isCompatible 结论。门禁显示的“涉及仓库”不能替代请求中的 PR 列表。\n- 请求解析失败保护：缺少可解析 PR 或有效 uuid 的请求不得进入兼容性分析、日志保存或门禁结论生成。自然语言中的 PR 线索只能作为待确认输入，不能从上下文补猜 PR，也不能使用空 uuid 落盘正式结果。\n- 请求身份不可变：从 parse_request.py 生成标准请求后，evidence packet、最终结果校验和结果保存必须复用同一个请求 JSON；禁止在中途删除 uuid、改写 content、缩减 PR 集合或重新手工拼接请求。manifest.uuid 必须等于请求 uuid，多 PR 结果保存必须显式传入该请求对应的 evidence_selected.jsonl；任何不一致都必须停止，不能在校验失败后继续保存或返回结果。\n- 多仓自测的关联扩展必须采用并集语义：原始输入 PR 是不可删除的种子，get_issues_by_pr -> get_prs_by_issue 发现的 PR 只能追加，不能用关联 PR 集合覆盖原始集合。入口应使用 merge_associated_prs.py 或等价逻辑生成 original_prs、associated_prs 和最终 prs；证据包 manifest 必须记录来源，校验时必须满足 original_prs ⊆ prs。若关联展开后缺少任一原始 PR，立即阻断，不得继续分析或保存。\n- 对工具/生成器类 PR，必须区分“当前 PR 修改了生成规则”与“知识库中存在相关生成规则”。只有当生成规则文件、公开 CLI/参数/退出码、打包入口、文档化流程或实际产物基线在本 PR diff 中变化，且能说明旧输入到新输出的用户可见差异时，才能以工具输出契约破坏判不兼容。仅由检索命中历史规则名、测试用例名、旧 cookbook 输出或未改动源码文件，不得推断当前 PR 改变生成产物。\n- 对工具/生成器输出的失败路径变化，必须区分“旧成功路径回退”和“未承诺失败路径改善”。如果旧生成产物在 unsupported/非法/缺失目标场景下原本 module load、import、初始化或编译直接失败，PR 改为 lazy/proxy/fallback/延迟访问时报错，只要旧成功输入、旧命令、输出名称、导入路径、签名、产物格式和文档化流程不变，且没有发布文档、机器解析协议、具体 golden/baseline 文件或兼容性测试明确承诺旧失败时机/错误文本，就不得仅凭失败时机、异常位置或错误文案变化判不兼容。\n- 当统一知识库查询返回 sqlite_relaxed、legacy fallback、历史案例或宽松关键词结果时，必须对每条候选证据做 PR diff 归属核验：`pr_diff_evidenc
• 结论：不兼容

⚠️ 当前目标分支不阻塞合入：兼容性接口判定为不兼容，但目标分支 feature/modal-type 允许忽略该结果继续合入。请相关开发者关注兼容性风险，并评估潜在影响。

提示：如需深度咨询，请联系 timi3。

✅ 以下PR将同时合入：

• Cangjie/cangjie_compiler#2065: fix: add local mode impl
• Cangjie/cangjie_test#2049: fix: add local mode impl
• Cangjie/llvm-project#606: fix: add local mode impl
• Cangjie/cangjie_runtime#1697: fix: add local mode impl
• Cangjie/cangjie_stdx#777: fix: add local mode impl
• Cangjie/cangjie_tools#1239: fix(lsp): adapt ty api

✅ The following PRs will be merged simultaneously:

• Cangjie/cangjie_compiler#2065: fix: add local mode impl
• Cangjie/cangjie_test#2049: fix: add local mode impl
• Cangjie/llvm-project#606: fix: add local mode impl
• Cangjie/cangjie_runtime#1697: fix: add local mode impl
• Cangjie/cangjie_stdx#777: fix: add local mode impl
• Cangjie/cangjie_tools#1239: fix(lsp): adapt ty api