fix(frontend): identify the default branch by its flag, not the name "main"

[bilalabbad]

What changed and why

main is the default default-branch name, not an invariant — a deployment sets it once through INFRAHUB_INITIAL_DEFAULT_BRANCH, and the backend resolves it from configuration everywhere. The frontend compared branch names against the literal "main" in six places, so on a deployment that renamed its default branch each of them silently reported the wrong answer.

Every comparison now reads the is_default flag the API already returns, and DEFAULT_BRANCH_NAME is deleted rather than left as a tempting constant.

Site	Before	After
branches-to-select-options.ts	pinned name === "main" to the top	pins is_default
branches-table.tsx	partitioned on name === "main"	partitions on is_default
events/ui/filters/global-branch-filter.tsx	skipped the filter when name === "main"	skips when is_default
diff/ui/checks/data-conflict.tsx	compared changes against "main"	compares against the proposed change's destination branch
shared/config/config.ts	/graphql/${branch ?? "main"}	omits the segment when no branch is given
branches/domain/model/branch.ts	DEFAULT_BRANCH_NAME = "main"	removed

Two of these were reaching for the wrong branch, not just the wrong name

The conflict view. A data conflict is between a proposed change's destination branch and its source. Comparing against "main" meant that for any proposed change targeting a non-default branch, both find calls picked arbitrary sides — a display bug on every deployment, not only renamed ones.

The GraphQL endpoint. Branch-agnostic callers — the branch list query, the create/delete branch mutations — were requesting /graphql/main. Where no branch is named main, registry.get_branch(db, "main") raises BranchNotFoundError and the endpoint returns 404 (backend/infrahub/graphql/app.py:135-138), so the branch list could not load at all. The server already serves /graphql without a branch segment and resolves its own default (graphql/api/endpoints.py:25-26), so the client no longer guesses.

User-facing copy

The unknown-branch toast said "you have been redirected to the main branch". It now says "the default branch". Both e2e suites assert that sentence verbatim, so frontend/app/tests/e2e/branches/branch-selector.spec.ts and tests/e2e/branches/test_branch_selector.py are updated in lockstep (the pytest case is renamed test_unknown_branch_redirects_to_default).

Documentation

A new dev/knowledge/frontend/branches.md records where the name comes from, why the flag is the only reliable test, and — the part that kept mattering here — which nearer source to reach for when the default branch is not actually the branch you want. It is registered in frontend/app/AGENTS.md with a load trigger, since a knowledge doc absent from that index never gets opened.

Testing performed

pnpm exec biome ci .    ✅
pnpm exec betterer ci   ✅ 190 issues (baseline unchanged)
pnpm knip               ✅
pnpm test               ✅ 167 files, 1148 tests
ruff format --check / ruff check on the touched pytest file  ✅

Two GraphQL endpoint assertions in client.test.ts compared CONFIG.GRAPHQL_URL() against itself, so they passed regardless of the URL shape; they now assert literal URLs and genuinely pin the omitted branch segment.

E2E not run — it needs a live stack. The assertions in both suites were updated together with the copy they check, and every is_default change is behaviour-identical when the default branch is named main, which is the configuration those suites boot. The only GraphQL route interceptions in either suite (login.spec.ts:154, test_login.py:159) match **/graphql/main** for the BuiltinTag operation, which is branch-scoped and still resolves to /graphql/main.

Note

No changelog fragment. CI only Vale-lints existing fragments (ci.yml:1085) rather than requiring one, but this is user-visible on renamed deployments, so say the word and I will add a fixed entry.

🤖 Generated with Claude Code

[cubic-dev-ai]

All reported issues were addressed across 15 files

<sub>Shadow auto-approve: would not auto-approve because issues were found.

Re-trigger cubic</sub>

[cubic-dev-ai]

0 issues found across 1 file (changes from recent commits).

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

<sub>Shadow auto-approve: would not auto-approve. Auto-approval blocked by 4 unresolved issues from previous reviews.

Re-trigger cubic</sub>