fix(pause-point): stop resuming Play for a marker that already hit

.agents/skills/uloop-pause-point/references/fast-progressing-games.md

@@ -28,6 +28,8 @@ Digit keys are `Digit0`-`Digit9` or `Numpad0`-`Numpad9` — bare `0`-`9` is reje
 
 `--resume-play` runs after the marker's arming is confirmed and before `--trigger` is dispatched: it resumes PlayMode only when PlayMode is actually paused, and reports what it did in `ResumePlayResult` (`WasPaused` / `Resumed` / `Error`; an abandoned wait adds `Repaused` / `RepauseError`). If the resume fails, the trigger is not dispatched and `TriggerResult.Error` says so. If the trigger itself is rejected before it runs, the wait is abandoned and the resume is undone: `Repaused: true` (or `RepauseError`) reports PlayMode being paused again, so gameplay cannot consume the preserved marker while the trigger value is being fixed. When the game reaches the line on its own after resuming (gravity, physics), omit `--trigger` and keep `--resume-play`.
 
+One case skips the resume on purpose: if the marker had **already** hit by the time the wait confirmed its arming (a single-shot marker, or any marker whose mode does not wait for a new hit — including one just armed by the same `enable-pause-point --await` call), the wait settles on that recorded hit instantly, so resuming would restart the game and then report an old hit. The wait returns the recorded hit and reports `ResumePlayResult.Skipped` (with `Resumed: false` and no `Error`); a `--trigger` given alongside is not dispatched and says so in `TriggerResult.Error`. Play Mode is left as it is (still paused when that hit paused it) — clear or re-enable the marker and wait again to capture a new one. An already-hit `continuous`/`trace` marker that was armed earlier is unaffected: its wait needs a later hit, so it still resumes.
+
 ## Do Not Use Time.timeScale = 0
 
 Projects that read unscaled time keep advancing regardless, and the value silently persists into the next PlayMode session. Editor pause and `Step` freeze the entire player loop independent of `Time.timeScale`.

.claude/skills/uloop-pause-point/references/fast-progressing-games.md

@@ -28,6 +28,8 @@ Digit keys are `Digit0`-`Digit9` or `Numpad0`-`Numpad9` — bare `0`-`9` is reje
 
 `--resume-play` runs after the marker's arming is confirmed and before `--trigger` is dispatched: it resumes PlayMode only when PlayMode is actually paused, and reports what it did in `ResumePlayResult` (`WasPaused` / `Resumed` / `Error`; an abandoned wait adds `Repaused` / `RepauseError`). If the resume fails, the trigger is not dispatched and `TriggerResult.Error` says so. If the trigger itself is rejected before it runs, the wait is abandoned and the resume is undone: `Repaused: true` (or `RepauseError`) reports PlayMode being paused again, so gameplay cannot consume the preserved marker while the trigger value is being fixed. When the game reaches the line on its own after resuming (gravity, physics), omit `--trigger` and keep `--resume-play`.
 
+One case skips the resume on purpose: if the marker had **already** hit by the time the wait confirmed its arming (a single-shot marker, or any marker whose mode does not wait for a new hit — including one just armed by the same `enable-pause-point --await` call), the wait settles on that recorded hit instantly, so resuming would restart the game and then report an old hit. The wait returns the recorded hit and reports `ResumePlayResult.Skipped` (with `Resumed: false` and no `Error`); a `--trigger` given alongside is not dispatched and says so in `TriggerResult.Error`. Play Mode is left as it is (still paused when that hit paused it) — clear or re-enable the marker and wait again to capture a new one. An already-hit `continuous`/`trace` marker that was armed earlier is unaffected: its wait needs a later hit, so it still resumes.
+
 ## Do Not Use Time.timeScale = 0
 
 Projects that read unscaled time keep advancing regardless, and the value silently persists into the next PlayMode session. Editor pause and `Step` freeze the entire player loop independent of `Time.timeScale`.

Packages/src/Editor/CliOnlyTools~/PausePoint/Skill/references/fast-progressing-games.md

@@ -28,6 +28,8 @@ Digit keys are `Digit0`-`Digit9` or `Numpad0`-`Numpad9` — bare `0`-`9` is reje
 
 `--resume-play` runs after the marker's arming is confirmed and before `--trigger` is dispatched: it resumes PlayMode only when PlayMode is actually paused, and reports what it did in `ResumePlayResult` (`WasPaused` / `Resumed` / `Error`; an abandoned wait adds `Repaused` / `RepauseError`). If the resume fails, the trigger is not dispatched and `TriggerResult.Error` says so. If the trigger itself is rejected before it runs, the wait is abandoned and the resume is undone: `Repaused: true` (or `RepauseError`) reports PlayMode being paused again, so gameplay cannot consume the preserved marker while the trigger value is being fixed. When the game reaches the line on its own after resuming (gravity, physics), omit `--trigger` and keep `--resume-play`.
 
+One case skips the resume on purpose: if the marker had **already** hit by the time the wait confirmed its arming (a single-shot marker, or any marker whose mode does not wait for a new hit — including one just armed by the same `enable-pause-point --await` call), the wait settles on that recorded hit instantly, so resuming would restart the game and then report an old hit. The wait returns the recorded hit and reports `ResumePlayResult.Skipped` (with `Resumed: false` and no `Error`); a `--trigger` given alongside is not dispatched and says so in `TriggerResult.Error`. Play Mode is left as it is (still paused when that hit paused it) — clear or re-enable the marker and wait again to capture a new one. An already-hit `continuous`/`trace` marker that was armed earlier is unaffected: its wait needs a later hit, so it still resumes.
+
 ## Do Not Use Time.timeScale = 0
 
 Projects that read unscaled time keep advancing regardless, and the value silently persists into the next PlayMode session. Editor pause and `Step` freeze the entire player loop independent of `Time.timeScale`.

cli/project-runner/internal/projectrunner/pause_point_resume_play.go

@@ -22,6 +22,12 @@ type pausePointResumePlayResult struct {
 	Resumed   bool   `json:"Resumed"`
 	Error     string `json:"Error,omitempty"`
 
+	// Skipped explains a deliberate no-resume that is not a failure, so the wait still reports the
+	// hit as a success. Why not Error: Error means the resume was attempted or refused and the wait
+	// treats it as broken (it skips --trigger), while this case is a correct outcome the caller
+	// still has to know about, because Unity stays paused by the hit that was already recorded.
+	Skipped string `json:"Skipped,omitempty"`
+
 	// Repaused reports that the wait put PlayMode back into pause after resuming it, which happens
 	// when the wait is abandoned because the --trigger command was rejected before it ran. Reported
 	// rather than kept internal: a caller that asked for a resume must be able to see that the