fix: wait for worktree start command launch

[Astro-Han]

Summary

Fixes the worktree start-command launch race exposed by the merged windows-advisory run after PR #1004.

• waits for a configured worktree start command to reach the process-spawn boundary before createReady / reset continue
• keeps stdout/stderr draining and process exit tracking in the background, so long-lived start commands still do not block prompt execution
• adds a deterministic regression test for the launch boundary and removes a Windows-sensitive shell marker assertion from the automation runner coverage

Why

The merged dev run for commit f9219cce6f58c54fd8191d9b2385d5530c037fa4 failed in windows-advisory on both unit-windows-opencode-config-project and unit-windows-opencode-server-tools.

PR #1004 correctly moved long-running worktree start commands out of the foreground path, but it forked the whole start-script task. That left no handshake for the middle state: the command has started, but has not exited. Windows scheduling exposed both sides of that race: callers could continue before the command had spawned, and tests with short wall-clock waits could misclassify slow Windows setup as waiting on command exit.

Related Issue

No separate issue. Follow-up fix for the merged PR #1004 CI failure: https://github.com/Astro-Han/pawwork/actions/runs/26709693626

Human Review Status

Pending

Review Focus

Please focus on the Worktree start-script launch boundary:

• the new Deferred<void> barrier should wait only until the first configured start command spawns
• long-lived start commands should still drain and exit in the background
• project start commands should still run before per-worktree extra start commands
• start-command failures should preserve the existing best-effort logging behavior

Risk Notes

Platform/CI: this targets a Windows CI failure in worktree start-command timing. The final branch was verified with both normal PR CI and a manual windows-advisory dispatch on the PR head.

Visible UI check skipped: no visible UI or copy changed.

Docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, and local-only docs were not changed.

XHigh review: a read-only reviewer found no blocking issues and judged the fix clean/elegant at the lowest correct layer. I applied its optional cleanup to make the launch barrier Deferred<void> because the barrier value is intentionally not consumed.

How To Verify

Diff whitespace check: git diff --check -> passed
Worktree regression suite: bun --cwd packages/opencode test test/project/worktree.test.ts --timeout 30000 -> 20 passed, 0 failed
Automation runner regression suite: OPENCODE_DB=:memory: bun --cwd packages/opencode test test/server/automation-runner.test.ts --timeout 30000 -> 22 passed, 0 failed
Worktree reset/remove adjacency suite: bun --cwd packages/opencode test test/project/worktree-remove.test.ts --timeout 30000 -> 4 passed, 1 skipped, 0 failed
Opencode typecheck: OPENCODE_DB=:memory: bun --cwd packages/opencode typecheck -> passed
PR checks: https://github.com/Astro-Han/pawwork/pull/1012/checks -> all required checks passed, including unit-opencode
Manual windows-advisory: https://github.com/Astro-Han/pawwork/actions/runs/26711660621 -> passed, including unit-windows-opencode-config-project and unit-windows-opencode-server-tools
XHigh reviewer: read-only review found no P0/P1/P2 issues

Screenshots or Recordings

Not applicable. No visible UI changes.

Checklist

How to use this checklist:

• Tick a box by replacing [ ] with [x]. Do not edit, add, or remove items.
• The bot-applied label items can only be honestly ticked AFTER the PR is opened and the labeler / priority-triage bots have run — return to the PR description and tick them then.
• Most items are required. The few that are conditional are explicitly marked (conditional); for those, leave unticked if they truly do not apply and explain why in Risk Notes. All other items must be ticked before requesting human review.

• Type label — this PR carries exactly one of bug, enhancement, task, documentation. Type labels are author-added; the labeler bot does NOT assign them. Add the label in the GitHub UI, then tick this.
• Routing labels — this PR carries at least one of app, ui, platform, harness, ci. The labeler bot assigns these on PR open based on changed paths. Confirm the bot's choice (or override if wrong), then tick this.
• Priority label — this PR carries exactly one of P0, P1, P2, P3. The priority-triage bot suggests one on PR open. Confirm or override, then tick this.
• Human Review Status above is set to Pending, Approved by @<reviewer>, or Not required: <reason> (default is Pending; "not required" is restricted to bot-authored low-risk PRs).
• I linked the related issue, or stated in Summary why there is no issue.
• I described the review focus and any meaningful risks.
• I replaced the example block in How To Verify with the real verification steps and the key result for each.
• I did not introduce unrelated refactors, dependencies, generated files, or file changes beyond the stated scope.
• (conditional) I manually checked visible UI or copy changes when needed, with screenshots or recordings. Leave unticked only if no visible UI or copy changed.
• (conditional) I considered macOS and Windows impact for platform, packaging, updater, signing, paths, shell, or permissions changes. Leave unticked only if no platform/packaging surface was touched.
• (conditional) I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, generated content, or local file changes when relevant. Leave unticked only if none of those surfaces was touched.
• I reviewed the final diff for unrelated changes and suspicious dependency changes.
• I am targeting dev, and my PR title and commit messages use Conventional Commits in English.

[coderabbitai]

Warning

Review limit reached

@Astro-Han, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 38 minutes and 3 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: ea392363-155a-4b4c-9218-76b35c984572

📥 Commits

Reviewing files that changed from the base of the PR and between f9219cc and fa2e611.

📒 Files selected for processing (3)

• packages/opencode/src/worktree/index.ts
• packages/opencode/test/project/worktree.test.ts
• packages/opencode/test/server/automation-runner.test.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/pr1004-windows-start-handshake

---

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 and usage tips.}

[github-actions]

Suggested priority: P2 (includes non-doc, non-test paths outside the low-risk bucket).

P1/P0 are reserved for maintainer confirmation. Please relabel manually if this is a release blocker, security issue, data-loss risk, or updater/runtime failure.

[gemini-code-assist]

Code Review

This pull request refactors the worktree start script execution to ensure that the start command has successfully spawned before the worktree creation or reset operation completes. This is achieved by introducing a Deferred signal to await the launch of the start scripts. Additionally, a unit test has been added to verify this behavior using a custom spawn probe. No review comments were provided, so there is no feedback to address.