experience-lwc-widget-assess

评估 LWC 是否适合改为 widget

针对每个 LWC 回答两个问题：能否呈现当前行为？ 如果不能，可行的 widget 是否仍能实现用户的目标？ 仅进行评估；不要创建元数据。widget 是独立的声明式构件，与 Lightning Type 不同。它的主体使用已发现的图块、绑定、公式和受支持的操作来呈现所提供的数据。它无法运行任意 LWC 代码、在渲染后获取数据，也无法保留响应式客户端状态。

证据与判断

1. 阅读组件的 JS/TS、模板、元数据和相关子组件。用一句话说明用户的目标。追踪每个可见值的来源，并识别实现该目标所必需的交互。@api 属性能证明存在外部输入，但不能证明可调用操作会返回该属性。用户明确说明操作输出的内容，可作为可行性评估的证据；在声称迁移可行前，先核实实际的操作契约以及 Lightning Type/渲染器的连线方式。
2. 将每个渲染元素和操作的用途映射到目标界面。platform-widget-generate 说明发现流程；实际的 discoverUiComponents 响应和 getUiComponentSchemas 结果才能确定可用的区块和属性。只有在转换确有影响时，才阅读其 references/widget-formulas.md。依据证据记录目标渠道，而不要假设渠道或磁贴数量固定。没有发现结果时，有文档记录的模式可以支持一个暂定候选项，但示例中未出现某个区块，并不能证明该区块不可用。若这一不确定性会影响结论，则使用 review；绝不要臆造磁贴、操作、输入提交机制或公式。
3. 即使某个维度未通过，也要检查所有维度：渲染词汇；保留的状态、命令式效果和操作；数据来源；以及转换。有限快照或预先整形的集合有时可以移入可调用操作的输出中。断言操作能够做到这一点前，先检查操作的实现。公式支持标量 MIN/MAX、日期或正则表达式，并不意味着它支持集合排序或聚合。输入表单需要有证据证明当前磁贴能够收集值，并且能将这些值传递给操作；仅凭 sendMessage 不能证明这一点。
4. 分别判断当前 LWC 和拟议的 widget。如果 Agent 确实能基于必要上下文执行所请求的工作，那么链接或 sendMessage 可能保留用户意图，但未必保留原有交互。轮播图可以改为产品列表；但如果订单构建器的用途是选择数量，就未必可行。应将这种变更视为重建。评估 widget 候选项的 rendersAsWidget 时，可以考虑一个明确指定的拟议 IA 契约；并明确说明契约变更。如果可行性或用途仍未确定，则使用 review，不要强行给出是或否的结论。

使用以下结果：

结果	含义
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	能力、数据来源或用途尚未确定。

在报告中列出所有实质性阻碍，并标明对应门槛及证据，引用源代码位置或具体行为。门槛名称为 role、rendering vocabulary、behavior/interactivity、data source 和 transformation。不要在遇到第一个未通过的维度后就停止检查。contractChange.shapeToAdd 仅填写操作有可能返回的字段或预先整形的值；绝不要臆造载荷。即使当前 LWC 的结论是 not-portable，可行的改造方案仍可能需要契约变更。如果拟议的 widget 会改变 UX，则设置 isRebuild: true，并在报告中说明失去的交互。对不确定的结论标记低置信度，并说明需要什么证据才能确定。

输出

生成两项产物。如果给出了输出位置，请将它们保存为 verdict.json 和 report.md。

判定 — experience-lwc-widget-migrate 所依据的机器可读决策。每个组件对应一个 JSON 对象；文件夹对应一个数组。请严格保留以下字段：

{
  "component": "caseDetailsPanel",
  "role": "renderer",
  "asIsVerdict": "port-declarative",
  "contractChange": {"suggested": false, "shapeToAdd": []},
  "asDisplayWidget": {"verdict": "viable", "rendersAsWidget": true, "stillServesPurpose": true, "isRebuild": false},
  "needsHumanReview": false
}

role 的取值为 renderer、input 或 interactive。stillServesPurpose 的值为布尔值或 "unknown"；如果能力尚未确定，rendersAsWidget 的值为布尔值或 null。对于 viable，两者都为 true。对于 pointless，渲染能力为 true，用途为 false。对于 blocked，渲染能力为 false，用途为 "unknown"。对于 review，未确定的字段保留为 unknown/null。对于 review 判定或用途未知的情况，将 needsHumanReview: true。仅当组件显示的值不在操作的输出中时，才建议更改契约（例如，该值是在渲染后获取的）。已在负载中的数据无需更改契约，即使 LWC 为 not-portable，或该组件是重建版本。任何建议的契约更改都必须提供非空的 shapeToAdd；needs-IA-contract-change 必须包含此类建议。port-declarative 不涉及契约更改。

报告 — 供人工审核的文档。对于文件夹，每个组件单独设一个章节。请使用以下结构：

# <component>: <one-line conclusion>

**Verdict:** <asIsVerdict> → <asDisplayWidget.verdict> (rebuild or not) · **Confidence:** high | low · **Needs human review:** yes | no

## Why
The user's goal, what maps cleanly, and what decides the verdict.

## Blockers
Each material blocker: gate, signal, evidence. "None" for `port-declarative`.

## Suggested contract change
Each field to add and why it must move into the action output. Omit when none is suggested.

## What the widget keeps / drops
Kept actions and dropped or replaced interactions.

## Open questions
What would resolve any low-confidence conclusion.