fix(broker): model the startup gate as a verdict, not two booleans

[khaliqgant]

Main is red. cargo clippy -- -D warnings fails: try_emit_worker_ready has 8 arguments against a limit of 7. My own #1529 added the eighth. Local cargo test does not run clippy, which is why it reached main — that is on me.

Rather than silence the lint with an allow, this collapses the two booleans clippy flagged into the tri-state they always were:

enum StartupGate { Ready, Unrecognised, Blocked }

Back to 7 arguments, and strictly better modelling. ready && blocked was representable and meaningless. More importantly the distinction that actually governs behaviour — a heuristic that failed to recognise the prompt may be overridden by the deadline; a harness deliberately refusing input never may — now lives in the type rather than a comment two call frames away. That was the exact hole two reviewers caught in #1529's first cut, so it is worth making unrepresentable.

No behaviour change. Ready is the old startup_ready, Blocked the old startup_blocked, Unrecognised the remaining case.

Verified: cargo clippy -p agent-relay-broker --lib -- -D warnings clean; 24 passed, 0 failed, including the veto guard.

Unrelated, for the record: the same CI run shows snippets::tests::mcp_preflight_requires_core_coordination_tools failing with Text file busy (os error 26) — a runner race writing the MCP executable while executing it, untouched by this change. And the Publish Package failure on Verify Standalone (macOS) was environmental: re-running the job with no code change passed all three standalone verifications.

🤖 Generated with Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[coderabbitai]

Warning

Review limit reached

@khaliqgant, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 2 minutes

Limit details: You’ve used all 4 included reviews currently available under your plan.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

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.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 891c3380-2eb0-4bf7-a7f1-93b02d444362

📥 Commits

Reviewing files that changed from the base of the PR and between 87ada40 and b05ad4f.

📒 Files selected for processing (1)

• crates/broker/src/pty_worker.rs

---

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.}

[cubic-dev-ai]

All reported issues were addressed across 1 file

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[khaliqgant]

relay-lead-0814 — all three findings addressed at b05ad4ff5. All three were valid.

Doc ownership (P3). Correct, and the mechanism is worth naming: my edit inserted the enum between startup_gate_blocked's doc comment and the function, so the enum silently absorbed documentation written for something else and the function was left undocumented. Each now carries its own block.

Duplicated veto note (P3). Correct. The explanation appeared above both startup_ready and timed_out. Kept once, above the timeout calculation it actually describes.

Over-indentation (P2). Correct — two of the three gate blocks sat at 32 spaces against surroundings at 16, because my edit used a fixed indent rather than matching context. Realigned to the call they precede.

One correction to that finding, because the next person will otherwise trust the wrong signal. The review predicted cargo fmt -- --check would fail. It does not — it passes clean both before and after my realignment, because rustfmt skips this function entirely (it sits inside tokio::select!). So the diagnosis was right and the predicted symptom was wrong. That matters: a green fmt gate is not evidence of correct formatting in this file, and had I checked only the gate I would have dismissed a real finding with a passing check to point at. Same shape as the ->pty:ready problem this PR chain came from — a tool reporting success on a path it never examined.

Verified: cargo fmt -- --check clean, cargo clippy -p agent-relay-broker --lib -- -D warnings clean, 24 passed / 0 failed including both readiness guards (unrecognised_prompt_releases_queued_work_after_the_deadline and a_blocking_dialog_is_never_timed_out_past).

Merging on Khaliq's explicit instruction — this unblocks clippy on main, which my own #1529 broke.