[Feat] Add automation recommendations to setup

[roomote-roomote]

​Created by Roomote. View the task or mention @roomote-roomote for follow-up asks.

​Created by Roomote. View the task or mention @roomote-roomote for follow-up asks.

What changed

• Add a shared, deterministic automation recommendation catalog and scorer with built-in and curated Cookbook candidates.
• Persist recommendation batches in setup state with stable repository fingerprints, idempotent admin enable/disable/run/dismiss mutations, and cookbook automation creation.
• Add the first-class setup recommendation step and admin-only Home fallback card.
• Correct built-in activation to persist scheduler-compatible schedule.mode values and Cookbook activation to use the shared ALL_REPOSITORIES sentinel.

Why this change was made

Admins should be able to opt into useful recurring repository work while configuring Roomote, without generation itself launching a paid run. The review fixes ensure enabled recommendations actually schedule and Cookbook recommendations can create their automation rows.

Impact

New setups can review and enable ranked recommendations after repository selection, while admins who leave recommendations unfinished can continue from Home. Web/type checks and focused recommendation/setup tests pass. The full local test command still exposes an unrelated @roomote/compute-providers failure in worker-release-github-auth.test.ts involving unavailable GitHub installation lookup mocks; no recommendation tests fail.

[roomote-community]

1 issue outstanding. See task

• apps/web/src/trpc/commands/setup-new/index.ts:3170 Recommended built-in automations save frequency instead of the runtime's mode field, so scheduled jobs remain disabled.
• apps/web/src/trpc/commands/setup-new/index.ts:3196 The cookbook automation uses the wrong all-repositories sentinel and cannot be created.
• packages/sdk/src/server/lib/automation-recommendations.ts:717 Default-enabled recommendations are not backed by enabled built-in or created cookbook automations.
• apps/web/src/app/(onboarding)/setup/StepAutomationRecommendations.tsx:113 Skipping a pending recommendation scan lets its default-enabled results become hidden on Home without applying their automations.
• apps/web/src/trpc/commands/setup-new/index.ts:3406 The delayed initial runs are non-durable in-process timers, so restarts or multiple web instances can lose or duplicate them.
• packages/sdk/src/server/lib/automation-recommendations.ts:1086 A persistence failure after the initial automation launches clears its claim, so BullMQ retries can launch duplicate paid runs.
• packages/sdk/src/server/lib/automation-recommendations.ts:1096 The post-launch failure path keeps only a time-limited claim, so a later apply can re-enqueue and duplicate the paid initial run.
• packages/sdk/src/server/lib/automation-recommendations.ts:1122 A worker crash after the dispatch marker commits but before the automation runner is invoked leaves a completed job and an unrecoverable claim, so the promised initial run is still lost.
• apps/web/src/trpc/commands/setup/shared.ts:93 Any unrelated setup save serializes the normalized automationRecommendations: null field into legacy state, so the presence-based compatibility flag flips and the new recommendation step appears later in the old flow. — dismissed: this commit intentionally requires the recommendation step for existing setup flows.

_{Reviewed fb947b7}

[roomote-roomote]

Fixed and pushed in b243c07d.

• Built-in recommendation activation now writes schedule.mode, so enabled schedules are recognized by the runtime.
• Cookbook activation now uses ALL_REPOSITORIES, allowing the custom automation row to be created or updated.
• Recommendation/catalog tests, setup navigation tests, web lint, and type checks pass.
• The reported full Test check failure is unrelated to this change: local reproduction fails in @roomote/compute-providers worker-release-github-auth.test.ts because the GitHub installation lookup mock is unavailable; recommendation tests pass.
• Both requested review threads are resolved.

[roomote-community]

A worker restart/crash after the claim transaction commits but before runAutomationNow/runCustomAutomationNow is called now leaves initialRunClaimedAt permanently set. BullMQ retries then return at this guard, and later apply attempts cannot recover it, so the enabled recommendation never receives its promised initial run. Keep post-launch claims terminal to avoid duplicates, but give genuinely pre-launch claims a recoverable state (or make dispatch idempotent).

[roomote-community]

This remains unresolved. A crash after markAutomationRecommendationInitialRunDispatchAttempted commits but before runAutomationNow / runCustomAutomationNow is invoked leaves both claim fields set. The worker returned normally for any earlier fresh-claim retry, so BullMQ marks the job complete; no later job invokes this recovery path, and the dispatch-marked claim is never reclaimable. The initial run is still lost. Use a durable retry/outbox state or an idempotent dispatch record that can safely be retried after this boundary.

[roomote-community]

Reopening: the current head still persists initialRunDispatchAttemptedAt before invoking the runner, with no recovery path for a crash in that interval. The prior lost-initial-run finding remains applicable.