[hivecommons-hive]

Summary

Forward-ports #14535 (the hygiene-merge baseline guard, merged to v5) onto v6, alongside the #14401 rewrite of the hold guard's mergeability upkeep.

Closes #14539

Why

#14535 made the hold guard advance a held PR's reviewed baseline only when the new head is provably the hive's own merge-from-base (holdguard.IsHygieneMerge: two parents, first is the head the hive asked to update, second is a commit on the base branch). Before that, a contributor push landing between the update request and the refetch could be adopted as reviewed hygiene.

v6 never received it: origin/v6:src/pkg/holdguard/holdguard.go has no IsHygieneMerge, and maintainHeldPRMergeability in src/cmd/hive/main_helpers.go calls store.AdvanceHygiene on whatever head it refetches. The automated v5→v6 forward merge is stuck (#14340), so this is a hand port, the same way #14548 ported #14308.

Change

git cherry-pick -x -s 62d4a09fb onto v6, then conflicts resolved by hand:

• src/cmd/hive/main_helpers.go: kept 🐛 fix(holdguard): one branch update per head and base; stop and say why #14401's flow (UpdateBranchExpectedHead per head and base, MarkUpdateRequested when the head has not moved yet, refusal stops). Added the IsHygieneMerge check from 🐛 fix(holdguard): advance the held baseline only on a proven merge-from-base #14535 right before AdvanceHygiene, using 🐛 fix(holdguard): one branch update per head and base; stop and say why #14401's head/base locals. The doc comment keeps 🐛 fix(holdguard): one branch update per head and base; stop and say why #14401's text and adds 🐛 fix(holdguard): advance the held baseline only on a proven merge-from-base #14535's proof requirement.
• Settle path: on v6, SettleUpdateRequest (when the head moves between ticks) only clears the pending request. It never advances the baseline, so AdvanceHygiene on a proven merge-from-base is still the only way the baseline moves. The settle path stays as it is.
• src/pkg/github/client.go: 🐛 fix(holdguard): one branch update per head and base; stop and say why #14401 already populates BaseSHA for held PRs in fetchPRsWithDetails, so I dropped the duplicate line the cherry-pick added. I also kept the enrichPRCI refresh and CommitOnBranch from 🐛 fix(holdguard): advance the held baseline only on a proven merge-from-base #14535. The BaseSHA doc now says the hold guard also uses it to key update attempts.
• src/cmd/hive/hold_guard_test.go: kept 🐛 fix(holdguard): one branch update per head and base; stop and say why #14401's refusal fields on the fake server and added 🐛 fix(holdguard): advance the held baseline only on a proven merge-from-base #14535's baseContains/compareCalls fields.
• Tests:
  • hold_guard_mergeability_test.go: the conflict test now uses 🐛 fix(holdguard): one branch update per head and base; stop and say why #14401's moved base (b2), so its merge commit's base parent is b2.
  • hold_guard_update_retry_test.go: …AsksGitHubAgainAfterAJournaledUpdate now uses real merge commits with parents (m1 = c1+b1, m2 = m1+b2), so the hive's own merges are still adopted.
• src/docs/scale-envelope.md: took the v6 side and moved the RankActionableIssues citation to client.go:4735-4745. check-api-reference-citations.sh --fix and check-docs-citations.py both pass.
• Changelog: the fragment is renamed to changelog.d/fixed-14539.md.

The behaviour on v6 now matches #14535 on v5, and #14401's per-head-and-base retry, wait and stop behaviour is unchanged.

I did not run the tests locally. CI will run them.

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[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 clubanderson 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

[github-actions]

Open PR overlap check

Base branch: v6

Conflicts are checked with every PR merged onto the current tip of v6, so a PR that only needs a rebase is not reported as conflicting with its siblings.

PR	Title	Relation	Files
#14399	🌱 chore: forward-merge v5 → v6 (slice 1 of 2: through 25dd844, before the pkg/agent→crux/agent rename)	same files	src/docs/scale-envelope.md src/pkg/github/client.go

[hivecommons-hive]

hive/awaiting-ci: CI pending — sweep will merge when green.

---

🐝 Hive Agent: scanner | Instance: hosted-available-oke-11-placeholder-r05x | SHA: unknown

— hive: agent=scanner backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Read the PR head (6c6ce29) against v6 and v5; this looks correct to me.

What I verified:

• holdguard.IsHygieneMerge (src/pkg/holdguard/holdguard.go:328-336) and Client.CommitOnBranch (src/pkg/github/client.go:3822-3833) are byte-identical to their v5 counterparts from #14535.
• The guard sits in the right place in #14401's flow: src/cmd/hive/main_helpers.go:369-395 runs after the newHead == head wait branch and before store.AdvanceHygiene, using the same head/base locals that UpdateBranchExpectedHead was keyed on. A failed proof continues without MarkUpdateRequested, so the next tick re-reads the moved head and the lift check sees it as drift — same semantics as v5.
• onBase fails closed: pr.BaseRef == "" and a CommitOnBranch error both return false (main_helpers.go:376-385).
• Parents flows end to end: ListPRCommits fills PRCommit.Parents (src/pkg/github/pr_commits.go:79-82,90), and the single fetchCommits closure at main_helpers.go:99 copies it into holdguard.Commit; that same closure is what maintainHeldPRMergeability receives at main_helpers.go:133, so the proof never sees an empty parent list from a stale path.
• go build ./cmd/hive/ ./pkg/holdguard/ ./pkg/github/ passes at this head (tests are CI-only on agent hosts; the agent/hub shards are already green).

One non-blocking note for whoever ports next: v5 additionally classifies the stale-head 422 from UpdateBranchExpectedHead (IsUpdateBranchStaleHead, #14537). v6 has no equivalent — ClassifyBranchUpdateError falls to the transient default and retries next pass, which is safe, just noisier. That is a separate forward-port, not a gap in this one.

— hive: agent=reviewer backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Evidence bundle `#145646c6ce29` sha256:07b3152e2c1f15d5008681e17053a89426849059402cf27c09afdd340cef4a1e — download from the dashboard or `hivectl review evidence #14564`.

[github-actions]

Thank you for your contribution! Your PR has been merged.

We'd love to hear how your experience was: share feedback