Lowcode ai product loop

Lowcode AI Product Loop

Use the current product entry to close one page-learning loop. This is an amendable operational baseline, not proof that the workflow, architecture, design system, component taxonomy, guardrails, or automation boundary is final.

Routing

Use this skill when the work centers on a fresh product page or an existing page in lowcode and must observe the real path through generation, import, Renderer, interaction, and evaluation.

Do not use it for:

• persisted real-chain scripts, run-record creation, or direct MySQL verification; use lowcode-ai-real-chain-runner;
• review of an already persisted run record; use lowcode-ai-run-review;
• code-only implementation, package publishing, deployment, or KB-only maintenance;
• an isolated model/provider harness that does not enter the product UI and Renderer.

Stable governance

• Read the relevant repository AGENTS.md, repository index, current P2C short card, and current TODO before acting.
• Treat code, direct tests, and real product evidence as stronger than KB or chat summaries.
• executionAuthorization defaults to none. This skill never creates authorization.
• A provider=0 qualification, candidate, freeze, package release, test pass, or prior authorization never permits a real provider call.
• One explicit authorization package applies only to its stated task, provider/model, external effects, budget, stop lines, and cleanup. Terminal completion or failure returns authorization to none.
• Use the existing product entry and production chain. Do not create a runner, schema, protocol, adapter, repair path, or fallback to make a run eligible.
• A routine operational correction inside an authorized package may be handled in the same task. Capability implementation, dependency changes, publishing, deployment, or materially broader effects require separate authority.

Required loop input

Before a real loop, freeze only the information needed to make the result attributable:

• one task identity and PRD;
• one exact H5 design profile for the task;
• design-source image or URL when source fidelity is in scope;
• viewport and relevant content assets;
• at least one expected interaction when the page is interactive;
• provider/model, maximum calls, token/cost/timeout envelope, and retry policy;
• evidence axes and terminal success/stop conditions;
• fresh-work identity and cleanup rule.

Do not mix two design profiles in one page task. A PRD-only task may test semantic generation, but it cannot establish design-source fidelity.

Workflow

1. Classify the mode

State exactly one:

• provider-zero-product-path;
• real-product-loop;
• same-page-observation-or-evaluation.

Do not silently switch modes.

2. Preflight the actual product entry

• Confirm current source/bundle freshness only when the process can plausibly be stale.
• Confirm required services and the product URL are reachable.
• Confirm the signed-in product session and fresh-work creation only through the product entry.
• Confirm the current generation/evaluation entry points and adapter from code; do not substitute a test harness.
• For provider-zero qualification, use the current product-entry direct suites for generation, evaluation, local calibration, and frontend import/Renderer. Do not treat the legacy test:ai-generation command alone as product qualification; it also contains retained Phase 2a/A+ compatibility suites and may depend on ignored historical tmp fixtures.
• Ignore historical console noise unless the current task's own request or UI state reproduces it.

If there is no existing executable product path to the intended boundary, stop and report the precise missing layer. Do not build a replacement.

3. Run one fresh generation

• Create a uniquely identifiable fresh H5 work through the UI.
• Enter the frozen inputs and trigger generation exactly as authorized.
• Record, without exposing secrets:
  • whether provider dispatch actually happened and how many attempts occurred;
  • whether the provider returned the required typed output;
  • whether host assembly and validation completed;
  • whether import completed;
  • whether Renderer is non-empty, visible, and editable;
  • whether the product UI reached a stable terminal state.

HTTP success, a valid spec, or a visible DOM alone is not the whole loop.

4. Exercise the frozen interaction

For each required interaction, record:

• initial visible/state condition;
• exact user action;
• expected result;
• observed UI/state result;
• console/runtime error attributable to the action, if any.

Do not infer interaction capability from static action bindings or schema validation alone.

5. Evaluate the rendered page

• Capture the current Renderer rather than the editor chrome.
• Use the existing screenshot/upload/evaluation path; do not embed an oversized image directly when the product path uses an asset URL.
• Run the existing hybrid evaluation at most as authorized.
• Keep deterministic contract findings, subjective design findings, source fidelity, interaction findings, and human Owner judgment separate.
• An evaluation success does not by itself make the page Page Draft Ready.

6. Attribute the highest blocking gap

Choose one primary layer:

• task/input or source evidence;
• provider/model typed-output behavior;
• AI authoring contract or orchestration;
• host identity/state/linking/validation;
• primitive/material/component capability;
• design-system expression or migration;
• runtime/action/interaction;
• frontend import/Renderer/terminal-state convergence;
• evaluation evidence or evaluator;
• product infrastructure.

Record secondary findings separately. Do not turn one sample preference into a new primitive or global prompt rule.

7. Close or hand off the small loop

• If an authorized capability fix was completed, retest the same page first.
• Only after same-page improvement should a new fresh task test reuse.
• If no implementation authority exists, return one bounded capability-gap candidate to the Owner.
• Clean up the uniquely identified fresh work through the product UI when the package requires it.
• Do not directly manipulate DB or Liveblocks for cleanup unless separately authorized.

Evidence boundary

Distinguish:

• real provider and real product evidence;
• provider=0 production-path evidence;
• direct code/test evidence;
• one-off negative evidence;
• unobserved layers;
• human judgment;
• historical clues.

Never promote a provider=0 pass, released package, mock page, fixture, or single visual sample into long-term architecture or generalized page capability.

Stop conditions

Stop the run, preserve the highest reached layer, and return to the Owner when:

• authorization, provider identity, external-effect scope, or remaining budget is unclear;
• the current product entry cannot create or identify the fresh work;
• the real product request reproduces an infrastructure failure;
• provider output, host validation, import, Renderer, interaction, or evaluation fails closed;
• UI terminal state does not converge within the frozen observation window;
• evidence or cleanup identity cannot be recovered safely.

Do not stop solely because the worktree is dirty, an unrelated warning exists, an old console entry is present, or a lower-level test harness is unavailable.

Unattended-readiness boundary

Do not call the loop unattended merely because npm publishing can be avoided with local links. Unattended execution also requires stable:

• service and bundle freshness checks;
• exact fresh-work identity and cleanup;
• provider budgets, timeout, and attempt accounting;
• product terminal-state convergence;
• screenshot/evaluation evidence capture;
• interaction execution and assertions;
• artifact/report persistence without secret leakage;
• fail-closed recovery that cannot delete or overwrite unrelated work.

Until those are demonstrated, use this skill as a bounded human-supervised baseline and record which step still needs supervision.

Output

Return exactly five layers:

1. 真实事实；
2. 证据边界；
3. route 状态与最高到达层；
4. Phase 2b-3 位置与能力缺口归因；
5. 唯一下一 Owner checkpoint、executionAuthorization 与 kbImpact。

Do not append multiple competing next routes.