SCE Preview Verify

Use this skill to turn "跑一下/预览/验证/截图看看" into an evidence-based loop. Do not stop at dotnet build when the request is about visible behavior, UI layout, GameGraph, particles, or runtime gameplay.

Pick The Run Mode

Need	Use
The user has the target project open in the GUI Editor	Prefer that editor unless the user explicitly requests isolation; diagnose its MCP connection before considering another host
No GUI is open and a target-project Headless session exists	Reuse that session and its Runtime MCP
No GUI is open, or the user explicitly requests isolation; AI verifies gameplay/server logic with one connected client	Prefer Headless through debug-tools; inspect installed capabilities and schemas first
UI Authoring, terrain interaction, editor resource preview or GUI-specific behavior	Full GUI Editor
Client-local UI, Canvas, GameGraph, particles or tools, with no open GUI or explicit user-requested isolation	client-only-debug
Multiplayer client orchestration	Full Editor multiplayer debug, or Headless exposing debug_create_game/debug_attach_client; inspect schemas through debug-tools
You already built and copied DLLs and only need a faster relaunch	debug-tools with debug_start_no_compile
Humanoid animation bake or resource statistics may be stale	debug-tools with debug_start_with_resource_statistics

Follow the shared host selection rules. Before direct client launch, read client-only-debug; before GUI or Headless build/debug, read debug-tools. A Headless debug client can have a visible window and supports screenshots and Runtime MCP. GUI and Headless must not write the same project concurrently.

Standard Loop

For client-only presentation with no open GUI or explicit user-requested isolation, the launch helper offers a one-shot evidence mode after building:

& ./ai/tools/Start-SceClientOnlyDebug.ps1 -ProjectRoot . -Preview -DeployClientDll -ExtraArgs @('-width=1280', '-height=720')

Use the current SDK's docs/ai/tools/Start-SceClientOnlyDebug.ps1 with an explicit -ProjectRoot if the project helper lacks -Preview. -DeployClientDll copies only the built client GameEntry DLL and verifies SHA256; this does not deploy a local runtime or test server logic. Omit it when the editor already copied the matching DLL. -ClientDllPath selects a nonstandard build output.

The helper rejects a mismatched project config, an occupied Runtime MCP port, or another running process for the project. It waits for debug.ping, verifies the returned project/run mode, then waits for the reported framework game start and startup-loading dismissal before capturing a unique PNG plus ui.snapshot. It writes startup.json, preview.json and current client-log tails to the evidence directory. Old runtimes without startup_state report startupEvidence.state=unsupported and a warning, rather than claiming verified readiness. Custom loading screens and gameplay state still need image/project checks; a responding MCP or HUD behind an overlay does not establish a playable view. -EvidenceDirectory, -ReadyTimeoutSec, -CaptureTimeoutSec, and -SettleMs control evidence location and bounded waits; settle time follows the startup check. It closes only its launcher/client PIDs, including on failure. For project-specific gameplay interaction, use the normal editor Runtime MCP loop; this one-shot preview captures presentation without driving controls.

success: true means evidence was collected, not that art direction or gameplay passed. Open the generated PNG before accepting the change.

The helper discovers scenegraph.render_snapshot and saves optional camera/Zone/light evidence to render.json. preview.json reports renderEvidence.state: captured, unsupported, discovery_failed, or failed. Old runtimes can still capture screenshots and UI; discovery/call failures remain diagnostic warnings. Candidate Zones and texture metadata do not prove the effective native Zone or resolved vignette mask.

1. Use the selected host's standard build/debug workflow for generation, both Debug configurations and deployment. For an explicit command-line build, compile both configurations unless the user only requests inspection:

dotnet build src/GameEntry.csproj -c Server-Debug
dotnet build src/GameEntry.csproj -c Client-Debug

2. Only for a manually built direct client launch or no-compile debug, deploy fresh DLLs. Standard GUI and Headless build/debug tools already handle deployment:

Copy-Item -LiteralPath "src/bin/Server-Debug/net9.0/GameEntry.dll" -Destination "AppBundle/managed/GameEntry.dll" -Force
Copy-Item -LiteralPath "src/bin/Client-Debug/net9.0/GameEntry.dll" -Destination "ui/AppBundle/managed/GameEntry.dll" -Force

3. For standard build-and-launch, follow the returned operation without another start. For direct client or no-compile mode, launch after deployment. Keep the original build/operation IDs through status/wait; query the same operation after a timeout before considering a retry.
4. Verify the runtime is reachable:
   • Runtime MCP available through GUI or Headless: call runtime_call_tool with debug.ping and correlate its project/run identity.
   • Shell fallback: use ai/tools/Invoke-SceRuntimeMcp.ps1 -Ping -Wait.
5. Capture evidence:
   • debug.capture_screenshot for visual state.
   • ui.snapshot, ui.find, or ui.get_rect for GameUI layout.
   • Current client/server logs at the selected host's returned paths.
6. Stop the owned debug run through debug_stop and verify its cleanup. Retain the managed host only for upcoming iterations when no editor binary update is pending; otherwise close it through debug-tools. Running SCE.exe / SCE.HeadlessEditor.exe may block binary replacement, so verify actual process exit before updating. For direct client launch, use its owned-process cleanup. Fix, rebuild and repeat until evidence matches the task.

Evidence Rules

• For cross-end state changes, define the expected server state, client-visible behavior and failure recovery before changing code. Correlate evidence from the same run, player slot and synchronized object ID. A successful call or a correct server position proves only that step; verify the client replica, control and actual interaction separately. Use readiness conditions with bounded waits rather than fixed delays. Report unverified paths explicitly, for example “服务端已验证，客户端待验收”.
• For SCE hero scene transitions, read sce-scene-transition. Verify entry, return, repeated transitions and controlled failure recovery, including hero identity, inventory, local main unit, HUD, camera and actual controls.
• For UI/layout work, prefer screenshot + ui.snapshot; Canvas-only drawing may not appear in the UI tree, so screenshot is the source of truth.
• For repeated PIE verification of a project-local loose image, stopping PIE automatically invalidates cached ordinary images below the current project's ui/ root (with compatibility cleanup for map-directory ui/ resources), so the next PIE should reload them. If an external tool replaces an existing file during the same PIE session, invoke project code that calls GameUI.ImageCache.Invalidate("<path below ui>") after the write completes and before the next use or screenshot. Treat the screenshot, not a true return value, as proof that pixels changed. Do not call this API every frame or leave it in normal production logic; newly added paths that previously failed lookup, atlas entries, packaged collections, Spine, fonts, GameGraph resources, and other CPU/native caches may still require their own rebuild or a Game View restart. See 项目资源路径指南.
• For server gameplay, inspect newest server logs and client logs. Project-root Client-Debug.log / Server-Debug.log are usually build output, not live runtime logs.
• For GameGraph rendering, verify a nonblank screenshot and inspect logs for missing resource, render path, or viewport warnings.
• A screenshot response with pending: true describes queued capture, not a readable image. Use Invoke-SceRuntimeMcp.ps1 -Wait: for PNG output it waits for a fresh file with complete PNG chunks and terminal IEND, not merely file existence. Keep the owned runtime alive through this wait.
• Capture a known working scene first. Replace one character, material, light, or render-path setting at a time and capture the same camera. When black output returns, locate the first changed item. Compare model identity, scale, facing, lighting shape, HUD, hit/death feedback, and restart with the supplied reference.
• For particles or animations, call debug_start_with_resource_statistics when baked resources may be missing.
• For behavior bugs, switch to behavior-troubleshoot after the first run shows the behavior is dynamic rather than a build/API/layout issue.

Related Skills

• wasicore-dev: compile configuration, AppBundle, runtime log locations.
• client-only-debug: direct pure-client launch and Runtime MCP bridge.
• debug-tools: editor MCP debug start/stop and Runtime MCP bridge.
• ui-layout-api: UI layout adjustment with screenshots and ui.snapshot.
• runtime-particle-builder: procedural particle preview/export loop.