用途：分析 KuiklyUI Compose DSL 的重组性能问题，适用于重组分析、重组优化、卡顿分析等场景。基于 Recomposition Profiler 输出，采用“report 筛查 → frames 深挖 → 源码确认”三阶段漏斗流程。
主要能力：先做数据健康检查（如 totalFrames 低于 minFramesThreshold 默认 30 会告警），再按 recompositionCount 排序筛查组件，识别单次耗时超标（singleRecompDurationThreshold 默认 10ms）、scope 集中、参数高频变化、State 订阅者过多等嫌疑项；随后逐行解析 profiler_frames.jsonl（JSONL 格式，须逐行 parse），结合 frame / touch_context / scroll_context 区分正常渲染开销与真实问题，并对耗时组件做链式根因推理。
使用方式：读取 references/config.md 获取默认阈值，用户可在请求中覆盖（如 scopeCountThreshold=10）。日志获取优先级：用户提供路径 → 约定路径 ./profiler_logs/、./profiler_report.json → 按 references/log-retrieval.md 从设备拉取（如 adb/xcrun/hdc）。缺少日志时提示先调用 RecompositionProfiler.start()/stop() 或使用 Profiler Overlay 录制。源码确认阶段取 sourceLocation（FileName.kt:行号），用 Glob "**/<FileName>.kt" 定位并读取函数及周边约 30 行。
适用场景：页面卡顿排查、重组次数异常优化、LazyList/LazyGrid/Pager item 重组分析、CompositionLocal 子树重组、参数稳定性与 remember 缓存评估。
限制：需已有 profiler 日志；参数索引可能无法映射到参数名；部分不稳定类型的 scope 重建等属于已知限制，参见 references/known-limitations.md。报告规范要求不写占比、不在问题描述使用规则代号、每个问题须给出重组次数与平均单次耗时，原因不明时应直接说明并给出排查引导，而非猜测。