从 issue 描述看，现象很明确：在 VSCode 中，当一个定义了 extend Int64（或其他基础类型）成员方法的 test.cj 文件没有被编辑器打开时，在另一个文件 aaa.cj 中对基础类型变量（如 num01）做点补全，无法补出 extend 中定义的成员（如 foo）；而一旦 test.cj 被打开过，补全就恢复正常。

这指向 LSP 的索引缓存机制问题：未打开的文件如果没有被纳入内存索引（mem index）或缓存分片缺失，extend 成员就不会参与补全解析。issue 已关联了一个 PR「fix: rebuild mem index when cache shard is missing」，标题方向与这个判断一致，说明问题大概率出在缓存分片缺失时没有触发索引重建。

cjc 版本为 1.3.0-alpha.20260921001050 (cjnative)，分支覆盖 main / release/1.0 / release/1.1 / release/1.2，需要确认该修复是否仅针对 1.3.0-alpha 还是需要回溯到已发布分支。

下一步排查建议：

1. 确认 PR 中修复的具体逻辑——是否在文件未打开时主动检查缓存分片是否存在，缺失时重建 mem index。
2. 验证 extend 成员的补全是否依赖文件级别的符号索引，而非项目级全局索引；如果是，这可能是根因。
3. 在修复后补充测试用例：extend 定义文件从未被打开时，新文件中对基础类型的点补全应包含 extend 成员。

issue 信息较完整，cjc 版本和分支都已提供，复现步骤清晰。建议维护者确认修复是否需要回溯到 release/1.0–1.2 分支，以及是否需要增加项目级索引预热机制来彻底避免此类缓存缺失场景。
@zjdd，@jyf219 看看，以你们确认的结果为准。