fix: agent-initiated destroys register with the Editor undo stack

[zorionarrillaga]

Thanks — all three taken, and you caught something I had wrong.

The description edits are gone entirely. You are right about Ctrl+Z: it is Cmd+Z on macOS, so
the line was false for half your users, and the token cost was not buying anything either way.

On the third comment — the reason the pre-6.5 file only had a description change is that I had
missed GameObject.Destroy.pre-Unity.6.5.cs completely. So the previous version fixed the code on
the 6.5+ side and the wording on the pre-6.5 side, which is backwards. That is now the code on both
sides and no description changes anywhere.

What changed

Three call sites, nothing else:

• GameObject.Destroy.cs:62 (#if UNITY_6000_5_OR_NEWER)
• GameObject.Destroy.pre-Unity.6.5.cs:62 (#if !UNITY_6000_5_OR_NEWER)
• GameObject.Component.Destroy.cs:88 (shared, no #if)

UnityEngine.Object.DestroyImmediate → UnityEditor.Undo.DestroyObjectImmediate, fully qualified
to match the existing UnityEditor.EditorUtility.SetDirty style in that folder, plus a CHANGELOG
entry under [Unreleased] → Fixed.

The other DestroyImmediate calls are untouched — Screenshot.Isolated, Screenshot.SceneView,
Screenshot.Camera, Screenshot.GameView, Assets.Prefab.Create and MainThreadDispatcher all
release temporary objects that do not belong on a user's undo stack.

Verification, and its limits

Compiled against Unity 6000.5.6f1, zero error CS, and
ToolThreadSafetyTests.GameObjectDestroy_BothThreads and GameObjectComponentDestroy_BothThreads
pass there. Undo.PerformUndo() restores the destroyed object after the new call and does not after
the old one, which is the behaviour the change is for.

⚠ 6000.5.6f1 is the only editor on this machine, so the #if !UNITY_6000_5_OR_NEWER branch was
never compiled. It is the same one-line substitution as its 6.5+ twin, fully qualified so it needs
no new using, but I have not built it and I would rather say so than imply I had.

Two things I did not decide for you

A Transform can now be destroyed where it previously could not. gameobject-component-destroy
iterates go.GetComponents<Component>() with no Transform guard, and the schema text points at
index 0. Object.DestroyImmediate refuses a Transform and logs an error; Undo.DestroyObjectImmediate
destroys and replaces it silently — the GameObject survives with a new Transform, and any serialized
reference to the old one becomes missing, with the tool still reporting success. It is undoable, but
it is a real behaviour change on an input the tool accepts. Happy to add a Transform/RectTransform
skip, or to leave it and note it, whichever you prefer.

Play mode. editor-application-set-state can put the editor into play mode, where Undo is not
meaningful. The call is unconditional here; a fallback to Object.DestroyImmediate while
EditorApplication.isPlaying is two lines if you want it.

[IvanMurzak]

Let's save tokens, remove this additional information.

[zorionarrillaga]

Done — the whole addition is gone, description unchanged from upstream.

[IvanMurzak]

Remove this line.
Side note: CTRL+Z is only relevant for Windows. On MacOS it is a false information

[zorionarrillaga]

Done, removed. And thank you for the macOS note — it is Cmd+Z there, so the line was false for half your users. It should not have been in a token-counted description in the first place.

[IvanMurzak]

This only the description update, but the code was not touched. It should no description changes if code hadn't been modified

[zorionarrillaga]

You are right, and the cause is worse than it looks: I had missed GameObject.Destroy.pre-Unity.6.5.cs entirely, so the branch fixed the code on the 6.5+ side and only the wording on the pre-6.5 side. Now it is the code on both sides and no description changes anywhere. One honest limit: 6000.5.6f1 is the only editor I have, so the !UNITY_6000_5_OR_NEWER branch is not compiled here.

[zorionarrillaga]

All three points are addressed in 980342e — the added text is out of both descriptions, and GameObject.Destroy.pre-Unity.6.5.cs now has the code change instead of only the wording. The diff is three call sites plus a CHANGELOG entry.

The red checks aren't from this change. All 12 Unity jobs stop at license activation:

##[error]Missing Unity License File and no Serial was found.
env:
  UNITY_LICENSE:
  UNITY_EMAIL:
  UNITY_PASSWORD:

test_pull_request.yml runs on pull_request with secrets: inherit, and GitHub withholds secrets from fork-triggered runs, so nothing compiles. The license-free jobs are green — nuget gate and both test-cli legs. The publish-test-results failure on main is downstream: workflow_run with no artifacts to download.

test-pull-request-manual from your side would get the license — I can't trigger that from a fork.

[zorionarrillaga]

Found the hinge for the red checks, in case it saves you a look. Before f473111d, test_unity_plugin.yml read UNITY_EMAIL: ${{ secrets.UNITY_EMAIL || '…' }}: the literal fallback meant a fork run got credentials without needing any secret. That commit dropped the fallback for a bare ${{ secrets.UNITY_LICENSE }}, and test_pull_request.yml has been on pull_request since dfa1699b, so fork runs now reach game-ci with the license empty. Same-repo runs are unaffected: task/r2-release-unity was 12/12 green on 08-24.

Separately: DestroySkill.Body in GameObject.cs and GameObject.pre-Unity.6.5.cs, AiSkillBody in GameObject.Component.Destroy.cs, and both destroy SKILL.md files still name Object.DestroyImmediate. I left them as they are because their code is unchanged, per your review. Say the word if you would rather the name matched.

[IvanMurzak]

Found the hinge for the red checks, in case it saves you a look. Before f473111d, test_unity_plugin.yml read UNITY_EMAIL: ${{ secrets.UNITY_EMAIL || '…' }}: the literal fallback meant a fork run got credentials without needing any secret. That commit dropped the fallback for a bare ${{ secrets.UNITY_LICENSE }}, and test_pull_request.yml has been on pull_request since dfa1699b, so fork runs now reach game-ci with the license empty. Same-repo runs are unaffected: task/r2-release-unity was 12/12 green on 08-24.

Separately: DestroySkill.Body in GameObject.cs and GameObject.pre-Unity.6.5.cs, AiSkillBody in GameObject.Component.Destroy.cs, and both destroy SKILL.md files still name Object.DestroyImmediate. I left them as they are because their code is unchanged, per your review. Say the word if you would rather the name matched.

Thank you @zorionarrillaga , I tried to fix it in the past. Could you please try to implement the fix in another PR? We can test that fix first, and then get back to this PR.