Configurable PR base branch (keep unique heads per feedback)

[ezzcodeezzlife]

Summary

Let owners set which git branch PRs target (e.g. develop, staging) instead of always using GitHub’s default_branch.

Do not add a mode where every feedback commit lands on one shared working branch. That would merge unrelated client requests into a single diff, guarantee conflicts, and destroy the “one feedback → one reviewable PR” product.

This issue is base branch selection, with unique head branches kept as they are today (feedback/f2c-{id}).

Current behavior

The pipeline always:

1. Resolves GitHub default_branch via GET /repos/{owner}/{repo} (cmdDefaultBranch in lib/feedback-agent/e2b/e2b-github.mjs).
2. Shallow-clones that branch (bootstrap-clone.sh: git clone --depth 1 -b "$BASE").
3. Creates head feedback/f2c-{id} (branchNameForFeedback in lib/feedback-agent/e2b-feedback-pipeline-core.ts).
4. Opens a PR with head=$F2C_BRANCH, base=$BASE (finalize-feedback.sh + create-pr).

There is no RepositoryConfig field for branch. Configure UI cannot set it.

Landing copy already shows branch: feedback/f2c-a1b2c3d4 as the head, which is the correct mental model.

Why the “one branch for all feedback” idea is a bad default

If we checked out client-feedback (or main) and committed every widget submit there:

• Unrelated CSS and API changes collide; the agent and the human cannot review one request.
• A bad submit blocks every later submit until revert.
• GitHub PR status on WidgetFeedback is keyed by prUrl (app/api/github/webhook/route.ts). One PR for N feedbacks cannot represent N statuses (CODING vs MERGED).
• Quota, emails, and dashboard cards are all per-feedback-row.

So: never “all feedbacks merged on one branch” as a product mode.

What is valid: all PRs target develop (or staging) because that is how the client’s GitFlow works. Each PR remains independent; they still conflict if they touch the same lines, which is correct and visible on GitHub.

Proposed design

Config

On RepositoryConfig:

prBaseBranch String?  // null = GitHub default_branch (current behavior)

Configure UI, under agent instructions or a new “GitHub” section:

• Label: Pull requests target
• Default: “Repository default branch (currently detected at run time)”
• Optional override: text field develop
• Helper: “Each piece of feedback still gets its own branch (feedback/f2c-…) and its own PR. This only changes what those PRs merge into.”
• Do not offer “commit all feedback onto this branch without PRs”.

Validate at save: 1–255 chars, Git ref-safe (^[A-Za-z0-9._/-]+$), no leading /, reject HEAD, reject feedback/f2c-* as a base (that would be circular).

Runtime

• Pass F2C_PR_BASE from the host instead of always calling default-branch, or call default-branch only when the override is null.
• Clone -b "$BASE" as today, with the resolved base.
• If the named branch does not exist, fail the run (FAILED) with a clear agentError: Base branch 'develop' not found. Surface on the dashboard. Do not silently fall back to main (wrong branch PRs are worse than a failed run).

Optional nicety: on configure save, hit GitHub API once to verify the branch exists (installation token already used elsewhere in lib/github-app.ts). Soft warning in UI, still hard-fail at run if deleted later.

Docs / marketing

FAQ or configure tooltip: review still happens on GitHub; targeting staging does not deploy. The agent still never pushes to the base branch directly (finalize-feedback.sh only pushes the unique head).

Assumptions

• Most users should leave this unset (GitHub default is right).
• Preview/deploy branches (gh-pages, vercel production branch vs git default) are the owner’s problem; we document “this must be a branch the GitHub App can push PR heads to”.
• Changing prBaseBranch does not rewrite open PRs. Open PRs keep their original base; GitHub allows changing PR base in the UI if they care.
• Iterate-on-PR (separate issue) checks out the head feedback/f2c-*, not the base. Base override still applies only when creating the PR.
• Protected branches: we never push to base; we only open PRs. If the org forbids PRs into main from bots, owners can point base at develop. That is a supporting reason for this feature.

Acceptance criteria

• Configure field to override PR base branch; empty = default_branch.
• New feedback PRs use that base; heads remain feedback/f2c-{id} and unique per submission.
• Missing/invalid base → FAILED with readable error, no PR against a random branch.
• Existing repos unchanged (null override).
• UI copy explicitly says we will not pile all feedback onto one branch.
• create-pr payload base matches the override (verify in E2B finalize env).

Out of scope

• Choosing a head branch name template (keep feedback/f2c-{id}).
• Opening PRs against a fork / upstream.
• Auto-rebase onto latest base on every run.
• “Stack all open feedback into one PR” — wontfix unless a future customer really demands it; if so, it must be a merge queue of already-reviewed PRs, not a shared dirty branch.

Implementation notes

• prisma/schema.prisma + configure server action (saveAuthorizedDomains already upserts RepositoryConfig — add the field there or split the Git section).
• lib/feedback-agent/run-e2b-feedback-agent.ts / e2b-feedback-pipeline-core.ts — pass base into sandbox env.
• bootstrap-clone.sh / finalize-feedback.sh — already use $BASE from f2c-base-branch.txt; write the override into that file instead of always shelling default-branch.
• Dashboard feedback list: show base ← head on the card if override is set (optional polish).

See also

• Iterate on feedback PRs (must keep unique heads; this issue only changes merge target)

[ezzcodeezzlife]

Related: iterate on PRs #3 — this issue only changes the merge target, not stacking all feedback onto one branch.