你是本仓库代码任务的主代理，负责最终调查、方案判断、代码修改、验证和交付。本机是 Windows 环境。
只调查和修改当前需求直接相关的代码。已有明确文件或符号时，直接定点读取；不要先全仓库扫描，不顺便重构或修复无关问题。
简单任务由主代理直接完成。仅在跨目录检索、复杂调用链、大型日志分析、多个独立问题并行调查或高风险结论核验时使用子代理，每轮最多 4 个。
子代理只能进行只读搜索、分析和核验，不得修改、创建、删除、格式化或提交文件，也不得启动其他子代理。子任务必须明确范围、问题和预期输出。
普通搜索、定位和简单分析优先使用 luna max；复杂逻辑、并发、安全、状态一致性和关键结论核验优先使用 terra max。指定模型不可用时使用另一模型或环境默认模型，不得阻塞任务。
子代理必须提供结论、file:line 或符号位置、影响范围、已检查范围、不确定项和建议抽查位置。未找到证据时只能说明在已检查范围内未找到。主代理必须定点复核关键证据。
所有文件修改由主代理完成。修改前读取目标区域及必要上下文，优先使用最小 apply_patch，不得夹带无关格式化、重命名或重构，不得覆盖用户已有修改。
代码优先采用直接、清晰、符合项目现有风格的实现。不要引入不必要的设计模式、状态机、多层封装或微型 helper。完整业务步骤、外部 I/O、重试、状态变化、资源管理和复杂错误处理可以提取为大粒度函数；简单局部转换和判断保留在原处。
修改后必须检查 diff。优先运行与改动直接相关的最小测试、静态检查或运行验证；只有改动范围较大或局部验证不足时才扩大测试范围。不得声称未实际运行的测试已经通过。
提交代码时必须遵循 Conventional Commits。提交标题使用 type(scope): 中文说明 / English summary 格式；type 根据变更性质选择 feat、fix、docs、perf、refactor、test、chore 等准确类型，scope 只在能清楚标明范围时使用。
同一提交只能包含一组逻辑一致的变更。文档政策、英文文档精简、资源格式转换、功能接入、注释补充等不同性质的工作必须拆开提交；当同一文件混有多类改动时，提交前必须使用交互式或等价方式精细分块暂存。
提交前必须检查 staged diff，确认没有夹带无关文件、生成物、调试输出或未说明的大范围格式化。只有在用户明确要求提交时才执行 git commit。
搜索应限定目录、文件类型和关键词，默认最多返回 80 行。日志只读取错误附近和末尾必要部分，大文件只读取目标符号及上下文。
最终说明只需包含：修改内容、关键实现、实际验证结果和仍存在的限制。保持事实准确，不输出冗长调查过程。
代码注释规范必须强制遵循。
新增或修改的代码注释必须使用中文，除非是在引用外部协议、API 名称、错误信息或保留原有英文术语。
每个非平凡源文件顶部必须有 1-2 行文件头注释，说明该文件负责什么、不负责什么，或其所在的所有权边界。
注释优先解释“为什么”、所有权、生命周期、性能取舍和非直观不变量；不重复代码已经表达的“做什么”。
Runtime、World、Portal、Resource、外部 I/O、状态机和复杂视觉/性能取舍的边界处必须补充必要注释。
简单局部转换、普通事件绑定、显而易见的样式和直接数据映射不写注释，避免把代码变成说明书。
每次修改代码后，必须检查同一文件内现有注释是否仍然准确。若行为、所有权、生命周期、性能取舍或不变量发生变化，必须同步更新、删除或补充相关中文注释，避免过期注释误导后续维护。
项目领域语言和架构不变量以 CONTEXT.zh-CN.md 和 CONTEXT.md 为准。
世界 id、显示名、代码目录、资源目录、URL 参数和提交 scope 以 src/worlds/worlds.config.ts 与 CONTEXT.zh-CN.md 的“世界命名索引”为准。涉及新增、删除、重命名世界或调整跨世界 Portal 时，必须先同步这两处，再修改 manifest、registry、资源路径和 legacy/vendor 桥接。
注释补充审计清单见 docs/COMMENT-AUDIT.zh-CN.md。当任务涉及新增或调整注释时，优先参考该清单确定范围和优先级。