enable-pause-point validation failures carry no RecommendedNextAction and no error code

[hatayama]

Summary

enable-pause-point rejects a Release-mode editor with a well-written explanation, but returns it as prose only: no RecommendedNextAction and no error code. A caller cannot detect the condition without matching English text, and an agent that follows the skill's own instruction finds an empty field.

Reproduction

Two commands against any project with the package installed:

# 1. put the editor on Release
uloop execute-dynamic-code --code "UnityEditor.Compilation.CompilationPipeline.codeOptimization = UnityEditor.Compilation.CodeOptimization.Release; return UnityEditor.Compilation.CompilationPipeline.codeOptimization.ToString();"

# 2. try to arm a pause point on any line inside a method body
uloop enable-pause-point --file Assets/Some/Script.cs --line 11 --timeout-seconds 60

Response:

{
  "Id": "",
  "ResolvedLine": 0,
  "Status": "",
  "IsEnabled": false,
  "Message": "Enabling a pause point by file and line requires Debug code optimization. The project is currently set to Release; switch the Editor's Code Optimization mode to Debug (the bug icon in the main toolbar) and recompile, then retry.",
  "RecommendedNextAction": "",
  "Success": false
}

The wording is helpful. What is missing is everything a program can branch on.

Details

The rejection comes from CreateValidationFailure, which only ever fills Success and Message:

unity-cli-loop/Packages/src/Editor/FirstPartyTools/PausePoint/PausePointTools.cs

Lines 630 to 637 in c0e392c

	private static PausePointResponse CreateValidationFailure(string message)
	{
	return new PausePointResponse
	{
	Success = false,
	Message = message
	};
	}

private static PausePointResponse CreateValidationFailure(string message)
{
    return new PausePointResponse
    {
        Success = false,
        Message = message
    };
}

Six failure paths go through it (lines 316, 322, 327, 387, 440, 446), including the Release rejection at line 440. By contrast the patch-failure path right below does populate the field:

unity-cli-loop/Packages/src/Editor/FirstPartyTools/PausePoint/PausePointTools.cs

Lines 455 to 458 in c0e392c

	Success = false,
	Message = patchResult.ErrorMessage,
	RecommendedNextAction = patchResult.Hint
	};

Success = false,
Message = patchResult.ErrorMessage,
RecommendedNextAction = patchResult.Hint

Problem 1: the skill points at a field that is always empty here

Packages/src/Editor/CliOnlyTools~/PausePoint/Skill/SKILL.md instructs:

If enable-pause-point fails, read the failure Message and RecommendedNextAction: they name the exact next step, for example waiting for a reload to finish, re-resolving after a recompile, or what to do when the method cannot be patched.

For all six validation failures that field is "". An agent doing exactly what the skill says learns nothing, and the guidance it needs is only in the prose it was not told to parse.

Problem 2: no machine-readable code

await-pause-point returns a full error envelope for its failures:

"Error": { "ErrorCode": "PAUSE_POINT_NOT_ENABLED", "Retryable": false, "SafeToRetry": ... }

The Release rejection has no equivalent. Detecting "this is fixable by switching to Debug" requires substring-matching an English sentence, which breaks on any rewording.

Why this is worth a code, not just prose

Any automation that restarts the editor walks into this condition without doing anything wrong, because the Debug setting does not survive uloop launch -r:

uloop execute-dynamic-code --code "UnityEditor.Compilation.CompilationPipeline.codeOptimization = UnityEditor.Compilation.CodeOptimization.Debug; return UnityEditor.Compilation.CompilationPipeline.codeOptimization.ToString();"
# -> "Result": "Debug"
uloop launch -r
uloop execute-dynamic-code --code "return UnityEditor.Compilation.CompilationPipeline.codeOptimization.ToString();"
# -> "Result": "Release"

So a long-running session that arms pause points, restarts the editor for any reason, and arms again, silently stops being able to arm at all. With an error code the caller can notice, re-apply Debug and retry; with prose only, every caller has to hard-code an English substring or treat the failure as unexplained.

This was found while endurance-testing the CLI against a large project: after the editor restart, every subsequent pause cycle failed, and because the response carried no code the failures read as unexplained. Identifying the cause took two full runs plus a targeted reproduction, where a code would have made it a one-line log and an automatic recovery.

Suggested direction

1. Give CreateValidationFailure a RecommendedNextAction argument and fill it at each of the six call sites, so the field the skill names is populated for every enable failure.
2. Attach an error code to the Release rejection (for example RELEASE_CODE_OPTIMIZATION), ideally through the same error envelope await-pause-point already uses, so callers can branch on it.
3. Worth considering for the skill as well: state that the editor's Debug mode is lost on uloop launch -r, since any workflow that restarts the editor mid-session hits this.

Environment

• uloop dispatcher 3.0.0-beta.24, project runner 3.0.0-beta.60, package 3.0.0-beta.66
• Unity 6000.3.15f1, Windows 11

[hatayama]

The endurance harness this was found with is now visible in #2046 (scripts/soak-loop.ps1 on feat/soak-loop-windows); the reproduction above does not depend on it.

[hatayama]

Fixed by #2048 (squash commit 5ab8f71).