fix(orchestrator): preserve queued_turn intent when promoting queued runs

[shivamhwp]

Summary

The five queued_turn/* replay-fixture failures on this branch (and everything stacked on it, e.g. the subagent-obs stack #4779–#4664) trace to a one-line regression in a73a9ff ("track provider retries and thread visits").

When a queued run is promoted after the active run finishes, the orchestrator rebuilds the run's user_message turn item and unconditionally stamps inputIntent: "turn_start" over the "queued_turn" intent the item was created with:

runs queued_turn/codex through OrchestratorV2 using deterministic replay
AssertionError: expected [ 'turn_start', 'turn_start' ] to deeply equal [ 'turn_start', 'queued_turn' ]

The same failure reproduces for all five providers (codex, claudeAgent, cursor, grok, acpRegistry) because the clobber happens in provider-agnostic promotion code.

Fix

Move inputIntent into the synthesized-fallback object only, so an existing turn item keeps its intent. The fallback stays semantically correct as "queued_turn" — a promoted run was queued by definition.

Verification

Bisected to a73a9ff (parent 1490bf9 passes, a73a9ff fails). With this fix at the branch tip:

• all 10 queued_turn replay tests pass (integration + contract)
• full OrchestratorReplayFixtures.integration.test.ts, ThreadLaunchService.test.ts, and Orchestrator.migration.test.ts: 168/168 pass

🤖 Generated with Claude Code

---

Note

Low Risk
Single-field intent preservation in orchestrator promotion with no auth, security, or data-model changes; behavior matches pre-regression semantics.

Overview
Fixes a regression where promoting a queued run after the active run finishes rebuilt the user_message turn item and always set inputIntent: "turn_start" on the merged object, overwriting queued_turn on items that already existed.

inputIntent: "queued_turn" is now only on the synthesized fallback when there is no legacy turn item; an existing item keeps its stored intent. Replay expectations (turn_start then queued_turn) and the five queued_turn provider fixtures are restored.

^{Reviewed by Cursor Bugbot for commit df97b7b. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Fix inputIntent to use queued_turn when promoting queued runs in Orchestrator

In Orchestrator.ts, the makeOrchestrator layer factory was incorrectly setting inputIntent to "turn_start" instead of "queued_turn" when constructing payloads for promoted queued runs. This corrects the intent value so queued run promotions are handled with the right intent.

^{Macroscope summarized df97b7b.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 869f9f51-45ae-437e-aa94-6d1495bf769d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Approved df97b7b

This is a straightforward bug fix that corrects the inputIntent value from "turn_start" to "queued_turn" when promoting queued runs, ensuring the semantic intent is preserved correctly. The change is minimal, logically correct, and self-contained.

^{You can customize Macroscope's approvability policy. Learn more.}

[shivamhwp]

Superseded by cee7589 on the base branch, which lands the same fix (promotion path now emits inputIntent "queued_turn") along with a unit-test update. Closing.