用途
该技能用于评估一个具体的 Lightning Web Component（LWC）能否作为 HXL 声明式 widget 来服务其用户的目的。它面向 LWC 到 widget 的可行性判断与可移植性分析。技能只做评估，不创建元数据。
主要能力
评估针对每个 LWC 回答两个问题：当前行为能否被表示？如果不能，一个可行的 widget 是否仍能达成用户目标？
评估过程包括：
- 读取组件的 JS/TS、模板、元数据以及相关子组件。
- 用一句话说明用户的目标。
- 将每个可见值追踪到其来源，并识别对该目标必不可少的交互。
- 将每个渲染元素和动作的职责映射到目标表面。
- 检查所有维度，即使某个维度已经失败：渲染词汇；保留状态、命令式效果和动作；数据来源；以及转换。
- 分别判断当前 LWC 和一个提议的 widget。
技能说明中强调：@api 属性只能证明存在外部输入，不能证明某个可调用动作会返回它。用户关于动作输出的明确陈述可作为可行性评估的证据，但在声称迁移可行之前，需要核实实际的动作契约以及 Lightning Type/renderer 的接线。
关于发现过程，技能提到 platform-widget-generate 解释发现流程；实际的 discoverUiComponents 响应和 getUiComponentSchemas 结果确立可用的块和属性。只有在转换重要时才阅读其 references/widget-formulas.md。目标渠道应从证据中记录，而不是假设固定的渠道或 tile 数量。没有发现过程时，有文档记录的模式可以支持一个临时候选，但示例中不存在并不能证明某个块不可用。当这种不确定性决定结论时，应使用 review；绝不虚构 tile、动作、输入提交机制或公式。
技能还指出：有界快照或预先成形的集合有时可以移入可调用动作的输出，但在断言之前应检查动作实现。公式对标量 MIN/MAX、日期或正则的支持并不意味着支持集合排序或聚合。输入表单需要证据表明当前 tile 能收集值并将这些值传递给动作；仅 sendMessage 不能证明这一点。
使用方式
技能定义了以下结果：
- asIsVerdict: port-declarative —— 当前可见行为和数据结构可以被表示。
- asIsVerdict: needs-IA-contract-change —— 只需要有界输出或预成形变更。
- asIsVerdict: not-portable —— 某些当前行为或视觉没有经过验证的等价物。
- asIsVerdict: review —— 证据无法确立当前适配性。
- asDisplayWidget.verdict: viable —— 一个经过验证或清晰识别的候选能服务目标，可能经过声明的契约变更或重建。
- asDisplayWidget.verdict: pointless —— 它可以渲染，但丢失了用户目标。
- asDisplayWidget.verdict: blocked —— 提议的显示/动作无法被表示。
- asDisplayWidget.verdict: review —— 能力、数据来源或目的未解决。
报告中需列出每个实质性阻塞项及其 gate 和证据，引用源位置或具体行为。Gate 名称包括 role、rendering vocabulary、behavior/interactivity、data source 和 transformation。不要停在第一个失败的维度。contractChange.shapeToAdd 只命名动作可能合理返回的字段或预成形值；绝不虚构 payload。一个可行的适配可能需要契约变更，即使当前 LWC 是 not-portable。如果提议的 widget 改变了 UX，设置 isRebuild: true 并在报告中指出丢失的交互。将不确定的结论标记为低置信度，并解释什么可以解决它们。
输出
技能产出两个工件。当给出输出位置时，将它们写为 verdict.json 和 report.md。
Verdict 是机器可读的决策，experience-lwc-widget-migrate 会以此作为门控。每个组件一个 JSON 对象；对于文件夹，则是一个数组。字段包括：
- component
- role（renderer、input 或 interactive）
- asIsVerdict
- contractChange（suggested、shapeToAdd）
- asDisplayWidget（verdict、rendersAsWidget、stillServesPurpose、isRebuild）
- needsHumanReview
其中 stillServesPurpose 是布尔值或 "unknown"；rendersAsWidget 是布尔值，或在能力未解决时为 null。对于 viable，两者都为 true。对于 pointless，渲染为 true 而目的为 false。对于 blocked，渲染为 false 而目的为 "unknown"。对于 review，未解决字段保持 unknown/null。对于任一 review 结论或目的 unknown，设置 needsHumanReview: true。仅当 widget 显示的值尚未在动作输出中时才建议契约变更（例如，它在渲染后获取）。已在 payload 中的数据不需要契约变更，即使 LWC 是 not-portable 或 widget 是重建。任何建议的契约变更都需要非空的 shapeToAdd；needs-IA-contract-change 需要这样的建议。port-declarative 没有契约变更。
Report 是人工审阅文档。对于文件夹，每个组件一个章节。结构为：
<component>: <one-line conclusion>
Verdict: <asIsVerdict> → <asDisplayWidget.verdict> (rebuild or not) · Confidence: high | low · Needs human review: yes | no
Why
用户的目标、哪些映射干净、以及什么决定了结论。
Blockers
每个实质性阻塞项：gate、signal、evidence。对于 port-declarative 写 "None"。
Suggested contract change
每个要添加的字段以及为什么它必须移入动作输出。没有建议时省略。
What the widget keeps / drops
保留的动作以及丢弃或替换的交互。
Open questions
什么可以解决任何低置信度的结论。
适用场景
适用于需要判断某个 LWC 能否作为 HXL 声明式 widget 使用、评估 LWC 到 widget 的可移植性、或在迁移前进行可行性评估的场景。
限制
技能只做评估，不创建元数据。widget 是它自己的声明式工件，与 Lightning Type 不同；它的主体使用发现的 tile、绑定、公式和支持的动作来渲染提供的数据，不能运行任意 LWC 代码、不能在渲染后获取数据，也不能保留响应式客户端状态。评估中不得虚构 tile、动作、输入提交机制或公式。如果可行性或目的仍未解决，应使用 review，而不是强行给出是/否结论。