galaxy/specs/APP-4118/PRODUCT.md

APP-4118: Toggle AI auto-gen + Enterprise gate for git operations

Linear: APP-4118 Parent: APP-3918 (git operations button) / APP-3071 (git operations in code review)

Summary

Git-operation dialogs in the code review panel (Commit, Push, Create PR, and their chained variants) currently call the code-review AI endpoint unconditionally, governed only by FeatureFlag::GitOperationsInCodeReview. They ignore the user's global AI toggle and expose an AI-backed draft to enterprise customers who should not have AI reaching their source. This spec gates every AI call in the git-operations flow behind the user's AI toggle and a hard enterprise check, so the feature degrades to a pure-manual experience when AI is not allowed — without hiding the git buttons themselves.

Behavior

When AI auto-gen is available

1. "AI auto-gen is available" means ALL of the following are true:
   • FeatureFlag::GitOperationsInCodeReview.is_enabled() (the parent feature flag).
   • AISettings::is_git_operations_autogen_enabled(app) returns true. That getter is itself is_active_ai_enabled(app) && *self.git_operations_autogen_enabled_internal, matching the sibling is_shared_block_title_generation_enabled getter. is_active_ai_enabled in turn composes is_any_ai_enabled (global AI toggle + auth state + remote-session org policy) with the active-AI internal toggle and AppExecutionMode::allows_active_ai(), plus a dedicated per-feature toggle the user can flip independently.
   • Either the user's current team is not enterprise, or the team is on the Warp Plan (internal Warp team), or the build is a dogfood channel build. This matches share_block_modal.rs::should_send_title_gen_request (lines 1161-1174) exactly, which exists for the same reason: our internal Warp team and our dogfood team are both tagged as enterprise customers and would otherwise self-disable AI on internal builds.
2. When AI auto-gen is available, the Commit, Push, Create PR, Commit-and-push, and Commit-and-create-PR flows behave exactly as they do today (see specs/APP-3918/PRODUCT.md). No regressions.

When AI auto-gen is not available

3. The primary git-operations split button, its chevron menu, and all dialog entry points remain visible and functional exactly as they are when AI is available. Git operations themselves do not depend on AI.
4. The Commit dialog opens with the "Type a commit message" placeholder immediately. It never shows the "Generating…" placeholder.
5. The Commit dialog does not issue any AI request when it opens. The message editor starts empty and remains empty until the user types something.
6. The Confirm button in the Commit dialog stays disabled until the user types a non-empty message, matching the existing "AI returned empty / failed" path — the user is never blocked on a network call that will not happen.
7. The CommitAndPush chain runs run_commit → run_push with the user-typed message, unchanged. It does not involve AI in any state, so it is unaffected.
8. The CommitAndCreatePr chain runs run_commit → run_push → creates the PR via gh pr create --fill (i.e. the existing AI-failure fallback path in create_pr_with_ai_content), without issuing any AI request for title or body. The resulting PR uses the latest commit's subject/body as title/body.
9. The standalone Create PR dialog (GitDialogMode::CreatePr) creates the PR via gh pr create --fill on confirm, without issuing any AI request for title or body.
10. Logs and telemetry emitted by the git-operations flow do not reference AI activity in this state. No "Failed to autogenerate commit message" warnings fire, because no request is attempted.
11. No toast, banner, or dialog copy tells the user AI is disabled. The absence of the "Generating…" state is the only user-visible signal; the feature simply degrades to manual.

State transitions

12. If the user flips the global AI toggle while a Commit dialog is open, the in-flight state of that dialog is preserved — any already-generated draft stays, any already-showing "Generating…" placeholder stays until the in-flight request resolves or fails. The toggle only affects dialogs opened after the change.
13. If the user's team customer_type changes (e.g. workspace switch) while a Commit dialog is open, the same rule applies: the open dialog keeps whatever state it was in; only the next-opened dialog reflects the new gate.
14. Toggling the global AI off mid-session and then reopening the Commit dialog yields the not-available behavior above. Toggling it back on yields the available behavior on the next open. 14a. In-flight AI requests are never proactively cancelled, including when the user's team customer_type or global AI toggle changes mid-request. The gate is evaluated once when the dialog opens and the result sticks for that dialog's lifetime, including the confirm-time CommitAndCreatePr chain and the standalone Create PR confirm. Only the next-opened dialog reflects any subsequent toggle or team change.

Interaction with existing gates

15. The overflow menu's "Add diff set as context" item continues to use its existing AISettings::is_any_ai_enabled gate (code_review_view.rs:7104). This spec does not change that gate, and does not add an enterprise check there — adding one is a follow-up if product decides.
16. The FeatureFlag::GitOperationsInCodeReview flag continues to gate the entire git-operations UI. When the flag is off, the gates in this spec are moot.
17. Remote-session org policy (is_ai_disabled_due_to_remote_session_org_policy) already flows through is_any_ai_enabled, which is_active_ai_enabled composes with — and the new is_git_operations_autogen_enabled getter composes with is_active_ai_enabled. Enterprise workspaces that disable AI in remote sessions get the not-available behavior without any separate plumbing.
18. The new per-feature setting git_operations_autogen_enabled_internal appears in the AI settings page alongside the other per-feature toggles (shared block title generation, code suggestions, etc.). Default: true. A user may flip it off independently of the global AI toggle.