Unity and DevelopmentUnity and codeAdvanced~8 min

Capstone: Unity Diagnosis to Verified Change

Snapshot

~85 sec

This capstone uses a completely invented Unity project to prove one controlled change loop: console evidence, narrow scene and prefab inspection, a written proposal, explicit approval, one bounded mutation, independent test and build-profile checks, an exact diff, and a concise evidence report. Use only enabled registered tools or established project and Unity surfaces.

You will learn

Execute a complete read, propose, approve, act, and verify loop on invented Unity content.
Combine registered MCP capabilities with Unity Test Framework, build-profile, and diff evidence without inventing tools.
Distinguish a successful mutation response from a verified capstone outcome.

Target outcome

You can run and report a bounded Unity MCP workflow whose authority, scope, and proof remain reviewable from start to finish.

01
Illustrative scenario: the invented PracticeArena project
- Observed symptom
  The disposable TrainingRoom scene logs a missing target reference when its generic CameraRig starts.
- Narrow target
  Inspection is limited to CameraRig, its target field, and the generic TargetDummy prefab used by the scene.
- Proposed outcome
  Assign the existing TargetMarker reference to one reviewed serialized field without changing components or sibling objects.
- Independent checks
  Use the established Unity Test Framework group, the generic development build-profile validator, and an exact version-control diff.
02
Run the capstone as one visible evidence chain
Every step uses invented project content. A registered Unity capability is used only when discovery shows it is enabled; otherwise the established script or manual Unity surface owns that step.
1. 1. Read console evidence
  Read only the recent missing-reference entries and reproduce the generic CameraRig symptom.
  narrows
2. 2. Inspect scene and prefab
  Read the CameraRig branch, target field, TargetDummy prefab identity, and relevant override state.
  grounds
3. 3. Write the proposal
  Name the exact field, reference, expected diff, rollback, and independent verification plan.
  requests
4. 4. Obtain explicit approval
  A person reviews the target, arguments, consequence, and scope before any write.
  authorizes once
5. 5. Perform one mutation
  Use one enabled reviewed Unity write capability or make the same bounded change manually.
  requires
6. 6. Run targeted tests
  Use the project's established Unity Test Framework runner for the named CameraRig group.
  continues with
7. 7. Validate build profile
  Use the established profile script or manual Unity surface; do not assume an MCP build tool.
  does not replace
8. 8. Inspect exact diff
  Confirm that only the approved scene or prefab field changed and no unrelated asset moved.
  supports
9. 9. Produce evidence report
  Record request and approval references, result, test and profile evidence, exact diff, and final verdict.
Every step uses invented project content. A registered Unity capability is used only when discovery shows it is enabled; otherwise the established script or manual Unity surface owns that step.
Reading order
1. 1. Read console evidence
  Read only the recent missing-reference entries and reproduce the generic CameraRig symptom.
2. 2. Inspect scene and prefab
  Read the CameraRig branch, target field, TargetDummy prefab identity, and relevant override state.
3. 3. Write the proposal
  Name the exact field, reference, expected diff, rollback, and independent verification plan.
4. 4. Obtain explicit approval
  A person reviews the target, arguments, consequence, and scope before any write.
5. 5. Perform one mutation
  Use one enabled reviewed Unity write capability or make the same bounded change manually.
6. 6. Run targeted tests
  Use the project's established Unity Test Framework runner for the named CameraRig group.
7. 7. Validate build profile
  Use the established profile script or manual Unity surface; do not assume an MCP build tool.
8. 8. Inspect exact diff
  Confirm that only the approved scene or prefab field changed and no unrelated asset moved.
9. 9. Produce evidence report
  Record request and approval references, result, test and profile evidence, exact diff, and final verdict.
Connection explanations
1. 1. Read console evidence → 2. Inspect scene and prefab (narrows)
  The reproduced console symptom identifies the smallest scene and prefab boundary worth inspecting.
2. 2. Inspect scene and prefab → 3. Write the proposal (grounds)
  Current serialized state supports a concrete proposal instead of a speculative edit.
3. 3. Write the proposal → 4. Obtain explicit approval (requests)
  The proposal exposes the precise mutation and verification plan for human review.
4. 4. Obtain explicit approval → 5. Perform one mutation (authorizes once)
  Approval applies only to the named field, reference, and attempt.
5. 5. Perform one mutation → 6. Run targeted tests (requires)
  The mutation response is not proof, so the matching Unity tests run independently.
6. 6. Run targeted tests → 7. Validate build profile (continues with)
  Targeted behavior evidence is followed by the established generic build-profile check.
7. 7. Validate build profile → 8. Inspect exact diff (does not replace)
  A valid profile does not prove edit scope; the exact diff checks what changed.
8. 8. Inspect exact diff → 9. Produce evidence report (supports)
  The final report links the approved intent to independent test, profile, and diff evidence.

Compare a bounded capstone with a broad autonomous edit

Approach	Context	Authority	Verification
Bounded evidence loopThe invented CameraRig issue stays within one symptom, one scene branch, one prefab identity, and one field.	Loads only recent related console entries and the relevant serialized objects.	Requests explicit approval for one exact mutation after presenting the proposal.	Uses a named test group, established profile check, visible Unity state, and exact diff.
Broad autonomous editAn agent scans all scenes, changes several references, saves assets, and reports tool success.	Pulls unrelated project data and obscures which evidence justified each edit.	Treats connection or one approval as permission for a chain of additional writes.	Uses the mutating tool's response as the verdict and can miss unrelated serialized changes.

Go deeper
The Controlled MCP Change Loop
Reuse the inspect, plan, approve, change, test, and review skeleton for the final workflow.
04
The final verdict advances only with independent evidence
The invented change is not complete when the tool returns. Each state adds a different proof source.
States
1. Mutation returned
  The enabled write capability or manual Unity action reports that the target field was assigned.
  Observable output: Tool-call or manual-action evidence exists, but task status remains unverified.
2. Targeted tests pass
  The established Unity Test Framework runner completes the named generic CameraRig tests.
  Observable output: Behavioral evidence passes for the reviewed boundary.
3. Build profile valid
  The generic development profile passes its established deterministic or manual validation.
  Observable output: The selected profile matches the capstone's reviewed build assumptions.
4. Diff exact
  Version control shows only the approved serialized reference change.
  Observable output: No unrelated scene, prefab, metadata, or settings change is present.
5. Task verified
  The evidence report links the symptom, proposal, approval, action, checks, diff, and final outcome.
  Observable output: The capstone can be reported as verified success with bounded evidence.
Transitions
1. 01
  Mutation returned → Targeted tests pass
  Input
  Run the named Unity Test Framework group through the established runner.
  Effect
  Behavior is checked outside the mutation response.
  Result
  Passing or failing test evidence is attached to the task.
2. 02
  Targeted tests pass → Build profile valid
  Input
  Run the established generic build-profile validation.
  Effect
  The workflow checks project configuration without inventing an MCP build command.
  Result
  A deterministic or manually reviewed profile verdict is recorded.
3. 03
  Build profile valid → Diff exact
  Input
  Inspect the exact version-control diff.
  Effect
  The operator compares actual serialized changes with the approved proposal.
  Result
  The diff is accepted only when no unrelated change exists.
4. 04
  Diff exact → Task verified
  Input
  Assemble the redacted evidence report.
  Effect
  Correlation and proof are preserved without copying secrets or broad project content.
  Result
  The final task verdict becomes verified success.
Warning
Unity Assistant MCP remains pre-release in this source set
The referenced Unity integration documentation is for Assistant 2.0.0-pre.1. Re-check the installed package, enabled tools, and current official documentation before running the capstone. Scene, asset, script, and console capabilities are usable only when the connected surface enables and registers them. Run targeted tests and build-profile checks through established Unity or project surfaces unless discovery proves a suitable reviewed capability exists.
Decide whether the capstone is complete
In the invented PracticeArena project, the approved CameraRig reference write returns success and its targeted tests pass. The build profile is valid, but the diff also contains an unrelated prefab metadata change. Can the task be reported as verified success?
Expected reasoning
No. Tool-call success, passing tests, and a valid profile do not override an out-of-scope diff. Keep the task unverified, identify how the unrelated metadata changed, revert or separately review it, rerun the required checks, and produce the evidence report only after the exact diff matches the approved proposal. Use enabled registered tools or established Unity and project surfaces; do not invent a build or test MCP tool.

Go deeper

Unity MCP 2.0: Get startedUnity's official connection and verification workflow; the documented 2.0.0-pre.1 package remains pre-release.
Unity MCP 2.0: Register custom toolsOfficial project-specific tool registration guidance for the pre-release Unity MCP package.
Unity Manual: Test FrameworkCurrent Unity reference for Edit mode and Play mode verification.
Unity Manual: Build ProfilesCurrent Unity reference for target-specific build configuration and reproducible platform checks.

You will learn

Target outcome

Illustrative scenario: the invented PracticeArena project

Observed symptom

Narrow target

Proposed outcome

Independent checks

1. Read console evidence

2. Inspect scene and prefab

3. Write the proposal

4. Obtain explicit approval

5. Perform one mutation

6. Run targeted tests

7. Validate build profile

8. Inspect exact diff

9. Produce evidence report

Reading order

Connection explanations

Compare a bounded capstone with a broad autonomous edit

States

Mutation returned

Targeted tests pass

Build profile valid

Diff exact

Task verified

Transitions

Mutation returned → Targeted tests pass

Targeted tests pass → Build profile valid

Build profile valid → Diff exact

Diff exact → Task verified

Decide whether the capstone is complete

Go deeper