Update — PATCH /{prID} edits title and/or body, validates title non-empty, returns prWithReviewers
Reopen — POST /{prID}/reopen transitions closed → open, fires webhook
Close now returns prWithReviewers and fires a webhook
Merge already existed; no changes needed
Frontend — PRDetailPage.tsx full rewrite:
Inline title editing — pencil icon (visible to author/admin when open), Enter to save, Esc to cancel
Inline body editing — same pattern in the description panel
Merge sidebar — radio buttons for allowed strategies (fetched from repo's merge strategy settings), "Merge pull request" button in Bitbucket purple, "Close without merging" below it
Status banner — merged (purple) or closed (grey) with the date, shown below the description
File list — scrollable +N −N table above the diff viewer showing all changed files with addition/deletion counts
Reopen button — appears in the sidebar when the PR is closed
Reviewers panel — lists assigned reviewers with avatars/initials
Details panel — from/into branches, opened date, last updated
Quick links — back to all PRs, open new PR
PRsPage.tsx — now shows real data:
Two tabs: "My pull requests" and "Awaiting my review" (with live counts from dashboard)
Per-repo quick links at the bottom showing open PR count badges
Aggregates repos, open PRs, review queue, open issues server-side
Per-repo PR and issue counts computed in one pass
Review queue pulls PRs where the user is an assigned reviewer (from pr_reviewers table), excluding their own PRs
Frontend — complete redesign of DashboardPage.tsx:
Section What it shows
Stats bar Repo count · My PRs · Reviews awaiting · Open issues — each a clickable nav pill
⌘K Command palette Fuzzy search across repos, PRs, issues with keyboard nav (↑↓ / Enter / Esc), quick-nav shortcuts when empty
Needs attention Only appears when review queue is non-empty; badges each PR as "Review requested"
My pull requests Open PRs I authored, with source→target branch, repo context, relative timestamp
My open issues Issues I filed, linked to the repo issue list
Workspaces My repos, prioritising recently visited (from useRecentRepos), with PR/issue count badges
CI/CD Honest placeholder until pipeline integration lands
Quick actions New repo · Import · Explore · Settings — always one click away
Empty state Shows only when user has zero repos
Repositories tab — lists all public repos as cards with owner/name link, description, default branch chip, last-updated time; sort by recently updated / newest / name A–Z; prev/next pagination
Users tab — grid of user cards with avatar/initials, username, join date; pagination
Skeleton loaders while fetching, opacity fade during page transitions
All state (tab, sort, query) reflected in the URL so links are shareable
Enable LFS toggle — turns LFS on/off for the repo; all other controls dim when disabled
File locking toggle — enables the LFS locking protocol for binary assets
Maximum file size — optional per-file size cap in MB (blank = unlimited)
Info callout linking to the git-lfs client install page and noting the .gitattributes requirement
CRUD rules with pattern (exact or glob like release/*), requirePR, blockForcePush, bypass user list
Enforcement via pkt-line parsing inside the git HTTP handler — before any data reaches git http-backend, each ref update is extracted and checked against stored rules
Direct push to main with requirePR: true → 403 with message; push to unprotected branches still works
Inline checkboxes in the UI update rules immediately
Branching model — stored config:
GET/PUT per repo, defaults to feature/bugfix/release/hotfix prefixes
Toggle enabled/disabled, custom prefix per type with live preview
No enforcement (naming guide only, as Bitbucket does)
Merge strategies — enforced in PR merge endpoint:
GET/PUT per repo, defaults all three allowed
Merge handler now accepts strategy: "merge"|"squash"|"rebase" in request body, checks against stored policy
Disallowed strategy → 409 with clear error; allowed strategy → merges and fires pull_request webhook
Must have at least one strategy enabled (validated server-side)
Webhooks — full delivery with HMAC:
CRUD with title, URL, secret (optional), events (push/pull_request/issue), active toggle
Test button sends live HTTP POST to the configured URL and shows status code in UI
FireWebhooks() fires asynchronously from PR merge and can be called from any handler
X-ForgeBucket-Signature-256: sha256=<hmac> header when secret is set
Last delivery status and timestamp stored on webhook record and shown in list
erangel1