[Feature]: Let Roomote recommend and fill project execution settings

[roomote-community]

Problem

Project execution, branch, merge, retry, concurrency, and approval settings are complex, especially for old or unhealthy repositories.

Proposed behavior

Add Ask Roomote to configure to project setup. Run a read-only analysis of branch protection, checks/reviews, CI/test health, environment readiness, repository hygiene, conventions, and likely indexing volume; fill the policy form with evidence, confidence, and warnings.

Reuse planning/explanation repository inspection, environment verification, source-control metadata, and the project policy form. Recommendations never save or activate automatically.

Acceptance criteria

• Recommendation cannot mutate project, repository, or provider state.
• Every suggested value has evidence or an explicit default rationale.
• Users can accept, edit, switch presets, or discard.
• Broken/legacy repositories receive conservative recommendations.
• Audit distinguishes suggested from authorized settings.

Dependencies

• [Feature]: Add the Projects dashboard and manual project setup #1038
• [Feature]: Add project integration branch configuration and preflight #1040
• [Feature]: Add Manual, Guided, Full auto, and Custom project execution policies #1045

[roomote-community]

I've analyzed this issue and here's my proposed implementation plan:

1. Build this after [Feature]: Add the Projects dashboard and manual project setup #1038, [Feature]: Add project integration branch configuration and preflight #1040, and [Feature]: Add Manual, Guided, Full auto, and Custom project execution policies #1045, reusing their project setup, repository branch mapping, immutable policy-version schema, authorization, and activity/audit primitives rather than introducing parallel project models.
2. Add a project-policy recommendation run and strict result schema covering every execution-policy field. Each proposed value should include confidence, evidence references or an explicit default rationale, warnings, and the repository SHA/environment verification state used during analysis. Store this as a suggestion artifact and audit event, never as an active policy version.
3. Launch the analysis from an Ask Roomote to configure action in project setup. Reuse the existing hidden-task and authenticated-result pattern used by apps/web/src/trpc/commands/setup/index.ts and apps/api/src/handlers/tasks/submitMcpRecommendations.ts, but enforce read-only execution: repository-scoped read permissions, no mutating source-control or project tools, and a result endpoint that can only submit recommendations for the matching project/run.
4. Add provider-neutral repository inspection, extending packages/github/src/api.ts first for branch protection, required checks/reviews, recent default-branch CI health, open-PR pressure, permissions, and repository size/activity. Combine that with checked-out repository conventions and test/CI manifests plus existing environment readiness fields (isVerified, verifiedAt, and verificationError). Missing provider capabilities must become low-confidence evidence gaps, not optimistic assumptions.
5. Normalize the findings through deterministic conservative rules: unhealthy, unverified, unprotected, legacy, or weakly observed repositories should default toward Manual/Guided execution, lower concurrency, bounded retries, explicit approvals, and no automatic merge. Multi-repository projects should receive per-repository branch/integration recommendations alongside shared execution settings.
6. Present the result as a reviewable overlay on the existing policy form: field-level evidence/confidence, prominent warnings, and actions to apply all recommendations to the unsaved draft, edit individual values, switch to a preset, rerun stale analysis, or discard it. Only the existing explicit save/authorize action may create and activate a policy version; audit should retain both the original suggestion and the final authorized values so edits are distinguishable.
7. Add schema/rule tests for evidence completeness and conservative fallbacks, authorization/idempotency/stale-result tests for the launch and submission paths, provider adapter tests for partial API failures, UI tests proving recommendations never auto-save and preset/discard behavior works, and public Projects documentation explaining confidence, warnings, and the authorization boundary.

This approach reuses Roomote's existing repository-analysis, environment-verification, task-result, and policy-form patterns while making recommendation generation read-only, explainable, and safely separate from authorization.

Please tag @roomote if you'd like me to implement this, or reply with feedback on the plan.