🐛 fix: name the base branch in every contributor task prompt

[Danathar]

Summary

The contributor task prompt never said which branch a task's work belongs on. A relay works one issue at a time out of a single persistent checkout and nothing resets it between tasks, so the base was whatever the previous task left checked out — which is how one [v5]-titled issue redirected four later PRs of a session onto v5, three of them fixes for defects live on the deployed v4.

This PR makes the prompt name the base branch. Every assignment now tells the agent which branch to start its work branch from and which branch to open the PR against, so the answer comes from the assignment rather than from whatever state the checkout is in.

What changed, concretely — the prompt gains one sentence:

Base this work on the 'v4' branch of kubestellar/hive. The checkout may be left on a DIFFERENT branch by a previous task, so do not use whatever branch you find there: run git fetch upstream and start your work branch from the base with git checkout -b <your-branch> upstream/v4. Open the PR against the same branch with gh pr create --base v4, and confirm the PR's base is 'v4' before you report done.

Where the base comes from (taskBaseBranch): the branch this hive was built from — the same upstreamBranch() the onboarding page's git clone -b command already names (#3990), so the branch a contributor cloned and the branch they are told to target agree. A branch-specific issue overrides it: a title leading with a release-line tag such as [v5] wins, because that issue really is v5 work whatever branch the hive runs.

The tag shape is deliberately narrow — v followed by digits and nothing else, the same ^v(\d+)$ shape pkg/hub/image_pulls.go matches and .github/release-lines.yml's release_lines lists. That keeps the lane prefixes the classifier already routes on ([quality], [architect], …) from being read as branches, and a tag naming no real branch fails loudly at gh pr create rather than silently redirecting the PR.

When no base resolves at all (a build with no injected branch), the prompt still refuses inheritance and names the substitute — the upstream repository's own default branch — instead of falling silent.

Why the prompt, and not the workspace

The issue reports a direct measurement, and it is the reason this PR is shaped the way it is: a working branch reset from v5 onto v4 mid-task, holding zero commits and a clean tree, was restored to v5 by the agent, because the plan it had already formed said v5. An agent follows what it was told over what it finds. Whatever the workspace says, the instruction has to carry the answer.

Live confirmation, incidentally: this task's own checkout was sitting on feat/5617-reviewer-lane-template (a v5 branch) when it started — the exact leftover state the issue describes. It was reset to upstream/v4 by hand before any work began.

Deliberately not included

Resetting the workspace to the base before each task. The issue calls this "a small change on the relay side", but bin/contributor-relay.sh performs no git operations at all today — it sets a cwd (TASK_WORKSPACE_DIR, line 129) and types a prompt; there is no git clone, git checkout, or git switch anywhere in it or in bin/contributor-agent.sh. Adding the reset therefore means a new task_assign protocol field plus a git reset --hard against a contributor's persistent checkout — a destructive new surface that deserves its own change, its own observation, and its own decision about what happens to unpushed work. Happy to file it as a follow-up.

One adjacent thing worth a maintainer's eye, not changed here: .github/PULL_REQUEST_TEMPLATE.md line 17 still reads "PR targets v2 unless a maintainer requested another branch." v2 is sunset and the default branch is v4, so the template currently points human contributors at the same class of wrong base this PR fixes for agents. Left alone because it is a human-facing policy line and outside this issue's scope.

Testing

• cd src && go build ./...
• cd src && go test ./pkg/dashboard/ — ok (50s), including the new cases
• go vet ./pkg/dashboard/, gofmt clean, python3 src/scripts/check-docs-links.py passes
• Mutation-checked: with the fix disabled (base passed as ""), 4 of the new tests fail; with it on, all pass
• cd src && go test ./... — pkg/agent, pkg/config, pkg/knowledge, pkg/proxy, pkg/sandbox fail in this sandbox (no tmux, read-only $HOME). Verified pre-existing: the identical five packages fail the same way on an unmodified upstream/v4 worktree. pkg/dashboard, the only package this PR touches, is green.

New regression coverage in src/pkg/dashboard/contribute_task_base_branch_test.go asserts the prompt names a base; that a task following a branch-specific one is told this hive's branch rather than the previous task's; that the base is derived rather than re-hardcoded to v4; that an uninjected build branch falls back instead of emitting unknown; that an unresolvable base still forbids inheritance; and that lane prefixes are not mistaken for release lines.

Related issues

Fixes #5729

Context from the incident: #5617 (the [v5] issue that started the run), #5688 / #5693 (the two-branch adjudication it produced), #3990 (the onboarding page's clone branch — same class, same source of truth).

Contributor checklist

• PR targets v4, the repository's default branch (the template's line still says v2; see above).
• Title uses the repo emoji convention.
• Commits include DCO sign-off (git commit -s).
• Docs updated — src/docs/contributor-relay.md gains a short section on where the base branch comes from.
• changelog.d/fixed-5729-task-prompt-base-branch.md carries the changelog entry.
• No secrets, credentials, or local runtime state are committed.

— hive: backend=claude model=claude-opus-5

[kubestellar-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign danathar for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[clubanderson]

/lgtm

[clubanderson]

Reviewed the diff against the requested base in a detached worktree. Validation: cd src && go build ./... plus targeted package tests for changed Go packages (and relay tests where applicable) passed locally. I found no blocking issues.

[kubestellar-prow]

LGTM label has been added.

Details

Git tree hash: 26f1e7dc5e4f6a21721b615f10fe89ea68602c46

[kubestellar-prow]

LGTM label has been added.

Details

Git tree hash: 26f1e7dc5e4f6a21721b615f10fe89ea68602c46