competition-bundle-sourcemap-recovery

竞赛捆绑包 Sourcemap 恢复

仅当 $ctf-sandbox-orchestrator 已处于活动状态，并且已建立沙箱假设、节点归属和证据优先级之后，才将此技能作为下游专业化使用。如果尚未发生这种情况，请先返回 $ctf-sandbox-orchestrator。

当运行时真相存在于构建产物、source map、chunk 表或混淆的 loader 流程中，而不仅仅存在于检入的源代码中时，请使用此技能。

除非用户明确要求英文，否则用简体中文回复。

快速开始

1. 从已提供的产物集合开始：入口 HTML、构建清单、引导 bundle、chunk 映射和 source map。
2. 在进行大范围手动反混淆之前，记录 chunk id、路由 chunk、loader 函数、端点字符串和配置键。
3. 重建能够解释当前哪个产物在执行的最小运行时图。
4. 除非已证明一致，否则将已提供产物的真相与仓库源代码分开保存。
5. 复现能够证明决定性行为的最小产物到运行时边界。

工作流

1. 映射已提供的产物集合

• 记录入口 HTML、script 标签、预加载提示、清单文件、产物映射、chunk 注册表和 source map URL。
• 注意框架特定的产物，例如路由清单、客户端引用清单或惰性加载器表（如果存在）。
• 将输出的文件名、哈希后缀和路由归属保持关联。

2. 重建运行时结构

• 跟踪引导代码、chunk loader、模块注册表、字符串解码器和惰性导入边界。
• 使用 source map、清单文件和稳定的符号簇来恢复路由名称、API 调用、功能标志和隐藏面板。
• 区分构建时意图与当前正在提供的 bundle。

3. 缩减到决定性的 bundle 路径

• 将结果压缩为最小序列：已提供的产物 -> loader 路径 -> 模块或符号 -> 运行时效果。
• 清楚说明决定性弱点存在于清单漂移、chunk 加载、隐藏路由代码、字符串解码还是过时的源代码假设中。
• 如果任务从构建产物转移到 SSR 或模板强制执行，请交回给更严格的模板渲染技能。

阅读此参考

• 加载 references/bundle-sourcemap-recovery.md 以获取产物清单、反混淆清单和证据打包。

需要保留的内容

• 已提供的文件名、chunk id、清单条目、source map 路径、恢复的符号和端点字符串
• 证明运行时分支的确切执行 bundle 或模块
• 达到决定性效果的一个最小产物到运行时序列