# Gameplay readiness inspection

`inspect_gameplay_readiness` collects one bounded report for an exact scene asset path.

```json
{"scenePath":"Assets/BallJumpGame/Scenes/MainScene.unity","includeReferencedPrefabs":true,"runStartupCheck":false}
```

The report contains loaded-scene and unsaved-state information; hierarchy and stable/global plus live instance IDs; component types; serialized reference identities and common scalar/vector values; null, broken and cross-scene reference observations; referenced prefab contents; current compilation diagnostics; and artifact-owner candidates exposed by the current task context. It does not read source code or inspect undeclared prefabs for scoped Kanban children. An unknown owner is explicitly reported.

Null fields may be optional. A null field alone is not an implementation defect. The report distinguishes scene components from components on referenced prefab assets, which may only become live after instantiation.

Limits: 200 objects, 600 components, 4,000 serialized properties, 16 referenced prefabs, and approximately 150,000 JSON characters before optional startup diagnostics. Strings are limited to 256 characters. Common scalar, Vector3 and object-reference values are included; complex values are not fully expanded as typed values. Truncation and skipped prefab reads are explicit. The report never declares full gameplay acceptance.

The capability requires Write permission because `runStartupCheck:true` can enter Play Mode. It reuses the existing run-owned Play Mode controller and attempts to exit afterward, including on cancellation. Startup is skipped when multiple scenes are loaded or the target is dirty. It preserves other scenes and never saves or repairs assets. A scene loaded solely for inspection is closed afterward.

Startup diagnostics include stack traces and matching script/component candidates where available. Unity's log callback does not supply an exact object instance, so candidate matches are never presented as confirmed attribution. Startup success does not verify movement, jumping, hazards, respawning, camera behavior, or victory.

Integration/gameplay verification cards automatically receive the static report before their provider run. The agent can request the guarded startup check afterward if needed. The combined report replaces redundant generic component discovery for those cards. Repeating the same static inspection on unchanged live evidence returns its previous report ID and a no-new-evidence message; changed data produces a fresh report. No cache survives the capability instance. Edit Mode `find_game_objects` calls also participate in the conversation engine's stable-observation no-progress guard; Play Mode searches remain volatile.

If image input is rejected outside the human-review policy (for example, an advertised image-capable provider rejects the request), Kanban preserves the attempt and pauses with `Retry Available` and an explicit provider configuration reason. No automatic retry is scheduled. Configure an image-capable model and endpoint, enable image input for that configuration, then use Resume. Static inspection cannot replace missing visual evidence.

Failed reviews can reopen a producer using the explicit upstream-artifact marker. If the marker is omitted, routing requires the exact owner card ID plus an unambiguous filename from the verification card's declared inputs. Ambiguous ownership, duplicate filenames, and locally owned outputs are not inferred.

## Human visual approval

When a Kanban run has no configured image-capable provider, its capture results retain screenshot paths, hashes and capture details as `HumanReviewArtifacts`. Image bytes are not sent to text-only providers. Other applications retain the strict image-input guard. The agent continues nonvisual checks and reports which visual checks remain; a successful screenshot capture is never visual proof.

Gameplay verification cards require the human gate even if the agent omits a capture. A successful automated review moves the card to **Awaiting visual approval**, with no automatic dispatch. Open the card's **Task Details**, use **Open screenshot**, and add notes describing what you checked. **Approve visual checks** completes the card only if automated review passed and the screenshot, input/output files and acceptance contract still match the reviewed snapshot. Save dirty scenes and leave Play Mode first. Missing or changed screenshots require **Refresh automated review and screenshots**.

**Request changes** records your feedback and sends the card through its existing rework and ownership routing. Approval is only for visual requirements; it does not waive missing runtime tests, upstream dependencies, or other acceptance criteria. Screenshot evidence and the human decision persist with the board. Generic movement to Done cannot bypass the human gate.
