feat(repositories): release target and routing rules settings

[brandonrc]

Summary

Adds two sections to the repository Settings tab.

Release target (#260): staging repositories can be linked to a local release repository of the same package format. The picker lists eligible local repos and saves through PATCH /repositories/{key} with release_repository_key. Selecting "No release target" unlinks. Non-staging repositories render a short notice explaining the control is staging only, and the section is gated to staging repos in the settings tab.

Routing rules (#263): view, add, edit, and remove path-rewriting rules for remote, virtual, and staging repositories. Each rule is a regex path_pattern and a rewrite_to template that can reference capture groups ($1, $2, ...). Rules are evaluated in order, first match wins. The backend stores a single ordered list, so every change saves the full set via POST /repositories/{key}/routing-rules; removing the last rule clears the config via DELETE.

Both sections reuse repositoriesApi with new getRoutingRules, setRoutingRules, deleteRoutingRules, and setReleaseTarget methods backed by the shared apiFetch helper, since the generated SDK does not expose these endpoints yet.

Closes #260
Closes #263

Test Checklist

• Unit tests added/updated
• E2E Playwright tests added/updated
• Manually tested locally
• No regressions in existing tests

UI Changes

• Playwright E2E spec covers the change
• Responsive layout verified (mobile + desktop)
• Dark mode verified
• Accessibility checked (keyboard navigation, screen reader)
• N/A - no UI changes

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[brandonrc]

Accessibility review (WCAG 2.2 AA) of release-target-settings.tsx and routing-rules-settings.tsx.

Positive findings

• Both sections use <section aria-labelledby> tied to a real <h3 id> (1.3.1, 2.4.6). Good landmark/heading structure.
• Release-target select: <Label htmlFor="release-target-select"> + SelectTrigger id are associated (4.1.2, 3.3.2). The non-staging case uses an Alert with an Info icon and descriptive text. Good.
• Routing-rules table: <Table aria-label="Routing rules"> is named; each editable cell <Input> has a unique aria-label ("Rule N path pattern" / "Rule N rewrite to"); each remove button has aria-label={Remove rule ${index+1}}. This is well done (4.1.2).

Gaps

1. Serious (3.3.1 / 4.1.3): validation feedback for add-rule and the backend "invalid regex" rejection is delivered only via toast.error(...). Toasts are transient and not programmatically associated with the Path pattern / Rewrite to draft inputs. A screen-reader user who submits an invalid pattern gets no field-level, persistent error. The add-rule draft inputs (the getByLabel(/^path pattern$/i) / /^rewrite to$/i controls referenced by the E2E spec) should set aria-invalid and aria-describedby pointing at a persistent role="alert" message on failure. The routing-rules-settings draft row appears not to render labeled draft inputs in the diff shown; confirm those draft inputs (a) have associated <Label>/aria-label and (b) surface errors via aria, not just toast.

2. Moderate: the <TableHead className="w-12" /> for the remove-action column is an empty header cell. Screen readers will announce a blank column header. Add visually-hidden text (e.g. <span className="sr-only">Actions</span>) so the column has a name (1.3.1).

3. Minor (1.3.1): the table uses <TableRow key={index}> with index keys; not an a11y issue per se, but reordering/removal can momentarily mis-associate the per-row aria-labels ("Rule N ...") with the wrong input during re-render. Names are derived from index so they stay correct after commit; just noting.

4. Minor (1.4.1): the rewrite arrow / $1 capture-group hint relies on <code> text, which is fine. No color-only meaning.

Not a hard blocker on its own, but item 1 (errors not programmatically associated) is the recurring a11y gap for new forms. Please wire the draft-input validation to aria before merge, or file a tracked follow-up. Review-only, not approving.

[brandonrc]

Test/E2E quality review (v1.2.0 batch). Verdict: the API contract tests are genuinely load-bearing; the UI tests are all admin-gated skips, which the PR honestly labels.

API tests (the real coverage). Both specs front-load strong, non-skippable API assertions:

• release-target (#260): asserts same-format link succeeds (200), different-format rejected (400), unlink via empty string succeeds, and non-staging repo rejected (400). Four distinct behavioral assertions including two negative cases. These prove the backend contract directly and cannot vacuously pass.
• routing-rules (#263): full set/get/delete round-trip asserting rules.length === 2, exact path_pattern/rewrite_to ordering, then delete and assert length === 0. Plus invalid-regex ( rejected with 400. Good negative case.

UI tests (weaker). Every UI: test has if (!settingsTab.isVisible) test.skip(...), and release-target additionally skips on "no eligible release repository option rendered". So in a non-admin or constrained CI seed, none of the UI-flow assertions run. The PR is upfront that "API contract tests are the load-bearing assertions," which is the honest framing, and the API tests genuinely cover the fix, so this is acceptable rather than theater. But note: if the Settings tab IS reachable in the e2e environment (it should be, the suite runs as admin), then these skips are silently masking that the UI path is never exercised. Worth confirming whether the e2e auth context actually reaches the admin Settings tab; if it does, the skip guards are dead weight hiding real coverage, and if it does not, then the entire UI layer of #260/#263 is untested. Please verify which.

One good detail: routing-rules UI tests use await expect(async () => {...}).toPass() polling against the API after the UI action rather than an arbitrary sleep, and the release-target negative UI test asserts toHaveCount(0) for the gated heading. Not requesting changes; please just confirm the admin-tab reachability so we know the UI skips aren't hiding a gap.

[brandonrc]

Frontend/React correctness review. No build blockers. One notable state-sync hazard worth addressing.

Notable: routing-rules edits can be silently discarded by a background refetch

routing-rules-settings.tsx uses the "adjust state during render" sync:

if (data?.rules && data.rules !== syncedRef) {
  setSyncedRef(data.rules);
  setRules(data.rules);
}

This compares by reference. TanStack Query refetches on window focus by default, and any refetch produces a new data.rules array reference even when the content is identical. When that happens while the user has unsaved edits in the table inputs, the render-sync fires and overwrites local rules with the server copy, discarding the in-progress edits with no warning. The dirty flag and Discard button don't protect against this because the reset happens outside the user's control.

Suggestion: gate the resync on not being dirty (only adopt server data when !dirty), or disable refetchOnWindowFocus for this query, or track edits in a way that survives a same-content refetch. At minimum, the resync should not clobber unsaved edits.

Suggestions

• ReleaseTargetSettings always starts at "No release target". selected initializes to NONE_VALUE and is never seeded from the repo's current link (the comment notes there's no GET for it). So an admin opening settings for a staging repo that already has a target sees "No release target" preselected; hitting Save without touching the dropdown sends an empty string and unlinks it. Consider disabling Save until the user explicitly changes the selection, or label the control clearly as "set/replace" so the empty default isn't mistaken for the current state.
• getRoutingRules has no error UI. On a fetch error data stays undefined, rules stays [], and the section renders the "No routing rules configured" empty state, masking the error as "no rules". Acceptable graceful degradation, but an explicit error state (like #465's rate-limits page uses) would be clearer.

Good

• API methods (getRoutingRules/setRoutingRules/deleteRoutingRules/setReleaseTarget) follow the existing apiFetch escape-hatch pattern correctly, with encodeURIComponent on the repo key and proper adaptRepository on the PATCH response.
• Query invalidations on mutation success are correct and target the right keys.
• Staging/remote/virtual gating in repo-settings-tab.tsx matches the feature semantics.

Merge sequencing (not a defect)

Overlaps #464 on repo-settings-tab.tsx. Known, will be merge-sequenced.

[brandonrc]

Shipped in v1.2.0. The changes from this PR were folded into the release integration branch #466, which was squash-merged to main and tagged as v1.2.0. The code is already on main, so closing this as superseded by #466 rather than merging it (re-applying would just duplicate what already shipped). No work lost. See #466 for the consolidated record.