Lowcode ai run review

Lowcode AI Run Review

Review saved lowcode AI real-chain run records and choose one evidence-based next action. Do not generate, repair, implement, edit code, call a provider, or mutate a database.

This skill requires a persisted run record or equivalent saved real-chain artifact. If the evidence exists only in the current product UI, a non-persistent fresh work, Renderer screenshots, interaction observations, or hybrid evaluation state, use lowcode-ai-product-loop instead of treating the missing run record as a defect.

Scope and evidence

• Start from the saved run record: runId, work id, page/input type, provider/model, timestamps, import/evaluation status, errors, diffs, persisted artifact refs, evaluator notes, and score details.
• Use manual notes and screenshots only as supporting context.
• Check whether the symptom repeats across runs, page types, or input patterns.
• Prefer run-record evidence over chat memory or subjective impressions.

If evidence is partial, state the exact minimum missing items before classifying with confidence.

Do not promote a persisted Phase 2a run into evidence that the current Phase 2b-3 product UI, import/Renderer, interaction, or terminal-state path has passed.

Classification

• Import issue: output cannot be imported, persisted, parsed, normalized, or rendered.
• Evaluation issue: scoring, repeat key, evaluator result, or label is missing, noisy, inconsistent, or not actionable.
• Manual issue: human review finds a UX, semantic, layout, or fidelity problem not captured well by evaluation.
• Input coverage issue: samples are too narrow or omit needed page/input variants.
• Frontend product follow-up: editor UX, asset replacement, interactive adjustment, or product decisions own the issue.
• No confirmed issue: evidence shows no reproducible actionable failure.

Priority is evidence classification, not execution authorization. P0/P1 may justify requesting an implementation decision after analysis, but never automatically authorizes implementation, provider calls, DB writes, reruns, or a new task. Treat P2 visual/calibration mismatches as observation unless repeated evidence proves product risk.

Decision

Choose exactly one primary action:

• Observe: weak, isolated, visual-only, or unreproduced evidence.
• Analyze: repeated symptom with unclear cause or owner.
• Implement: sufficient P0/P1 evidence and likely engineering ownership; this is a recommendation requiring separate authorization.
• Validate: an existing fix, evaluator change, or workflow claim needs a targeted rerun or matrix update; the rerun requires its own authorization.
• Route: editor/product workflow owns the issue.

Never recommend server hardcoding from one random sample.

Evidence-insufficient output

Return Evidence insufficient or Observe, list only the minimum missing evidence, give a tentative bucket only when supported, and request the smallest concrete artifact, preferably a run record or runId.

Output

结论：<observe/analyze/implement/validate/route/evidence insufficient>
分类：<import/evaluation/manual/input coverage/frontend product/no confirmed issue>
优先级：<P0/P1/P2/Observation>
依据：<concise run-record evidence>
授权边界：<recommendation only / separate approval required, when relevant>
下一步：<one concrete evidence or decision request>