Assess LWC to widget fit

Answer two questions for each LWC: Can the current behavior be represented? If not, would a feasible widget still accomplish the user's goal? Assess only; do not create metadata. A widget is its own declarative artifact, distinct from a Lightning Type. Its body renders supplied data with discovered tiles, bindings, formulas, and supported actions. It cannot run arbitrary LWC code, fetch after render, or retain reactive client state.

Evidence and decision

1. Read the component's JS/TS, template, metadata, and relevant child components. State the user's goal in one sentence. Trace each visible value to its source and identify interactions essential to that goal. An @api property proves external input, not that an invocable action returns it. A user's explicit statement about action output is evidence for a feasibility assessment; verify the actual action contract and Lightning Type/renderer wiring before claiming a working migration.
2. Map the job of each rendered element and action to the target surface. platform-widget-generate explains the discovery procedure; the actual discoverUiComponents response and getUiComponentSchemas results establish available blocks and attributes. Read its references/widget-formulas.md only when a transformation matters. Record the target channel from evidence rather than assuming a fixed channel or tile count. Without discovery, a documented pattern can support a provisional candidate, but absence from examples does not prove a block is unavailable. Use review when that uncertainty determines the verdict; never invent a tile, action, input submission mechanism, or formula.
3. Check all dimensions, even after a failure: rendering vocabulary; retained state, imperative effects, and actions; data origin; and transformations. A bounded snapshot or pre-shaped collection can sometimes move into the invocable action's output. Inspect the action implementation before asserting that it can. A formula's scalar MIN/MAX, date, or regex support does not imply collection sorting or aggregation. Input forms require evidence that the current tiles can collect values and pass those values to an action; sendMessage alone does not prove that.
4. Judge the current LWC and a proposed widget separately. A link or sendMessage may preserve an intent without preserving the original interaction, if the agent can actually perform the requested work with the required context. A carousel may become a product list; an order builder whose purpose is choosing quantities may not. Treat that change as a rebuild. For the widget candidate, consider a specified proposed IA contract when setting rendersAsWidget; state the contract change explicitly. If feasibility or purpose remains unresolved, use review, not a forced yes/no verdict.

Use these outcomes: