fix(github-actions-grafana-jump): show jump links on the repo home page at a branch

[nsheaps-oura]

Stacks on #53 and is based on its branch, so it should merge after it. Reuses the ref-disambiguation DOM reading that PR added.

The bug

Switching the branch selector on a repo's home page navigates to /org/repo/tree/<ref>. No page parser recognized that URL shape, so nothing matched and the toolbar buttons vanished until you switched back to the default branch. Reproduced live before the fix: the "Set up links" button is in the header on /nsheaps/greasemonkey-scripts, and gone after picking a branch.

What it does now

/org/repo/tree/<ref> (the repo root at a ref, nothing after it) resolves to the existing repoHome page kind, carrying the ref it's viewed at.

• Why reuse repoHome instead of a new page kind — it is the same page. Verified against the live DOM that [data-testid="repo-header-actions"] (the <ul> the repoHome links are injected into) is present with the same shape there, both on a hard load and after the branch-selector navigation.
• A directory below the root (/tree/<ref>/<path>) stays unmatched, as the existing comment said it should — that element is genuinely absent there, so it really is a different page with a different header. Out of scope here.

URL	repo-header-actions	resolves to
/org/repo	present (<ul>)	repoHome, no ref
/org/repo/tree/main	present (<ul>)	repoHome at main
/org/repo/tree/n8bot/branch-ref-disambiguation	present (<ul>)	repoHome at that ref (via DOM)
/org/repo/tree/main/packages	absent	nothing (unchanged)

Branch-aware config, too

The page reads .github/jump-links.config.yaml from the ref it's showing, the same lookup a file view and a branch-filtered Actions tab already do since #51. This is one of the pages you actually land on while trying a config change out on a branch before merging it, so it would be odd for it to keep reading the default branch.

The ref is deliberately not exposed as a {{branch}} field. Which fields the repo home page offers shouldn't depend on whether you got there with a ref in the URL, or a link configured for that page would appear and disappear as you switch branches.

The slashed-ref ambiguity

/tree/renovate/all-patch is equally readable as the root at ref renovate/all-patch or directory all-patch at ref renovate — the same ambiguity #53 documents for /blob/.

flowchart TD
    A["/org/repo/tree/&lt;rest&gt;"] --> B{"one segment<br/>after /tree/?"}
    B -->|yes| C["repoHome at that ref<br/>(pure, from the URL)"]
    B -->|no: ambiguous| D{"does the page's own<br/>resolved ref account for<br/>the whole remainder?"}
    D -->|yes| E["repoHome at that ref"]
    D -->|"no (leftover path)"| F["no match: directory view"]
    D -->|"DOM hasn't answered yet"| G["no match; re-check on<br/>the next DOM mutation"]

Loading

The single-segment form is read purely from the URL. The ambiguous form is settled against the ref GitHub itself resolved the page to, read from #53's same two DOM sources (the ref-picker aria-label and the embedded refInfo.name) and only trusted when it accounts for the whole path. When neither source answers, the URL stays unmatched rather than being guessed at — and mayBeUnresolvedTreeRoot() keeps it re-checking on later DOM mutations so a header that hadn't rendered on the first pass is still picked up.

Verification

Live, in the browser (github.com, this repo):

• Reproduced the bug: buttons present on /nsheaps/greasemonkey-scripts, gone after switching to n8bot/branch-ref-disambiguation via the branch selector.
• Confirmed repo-header-actions presence/absence per the table above, on hard loads and after the client-side branch switch.
• Confirmed both DOM ref sources are present and exact on /tree/<slashed ref> — aria-label="n8bot/branch-ref-disambiguation branch" and refInfo.name — on a hard load and after the soft navigation.
• Injected the wrapper the renderer builds (<li> + Primer classes) into that page's header: it renders inline and styled like GitHub's own buttons.

Code-correct: yarn test — 87/87 pass, including new coverage for the tree-root parser, the ambiguous multi-segment cases, refMatchesTreeRootPath, mayBeUnresolvedTreeRoot, and the branch threading through repoContextForJump/repoConfigCacheKey/repoConfigUrl. yarn install --immutable, yarn build, yarn lint all clean. Additionally ran the built dist/index.js DOM path against the exact strings captured from those live pages.

Not verified: the finished userscript running end-to-end as an installed script on a /tree/<ref> page. The built script couldn't be injected into github.com (its CSP blocks loading it), and installing a dev build into the browser's script manager would change local browser config, so it wasn't done. The rendering half is unchanged code already working on /org/repo, and its injection point was confirmed live on the tree page.

Co-Authored-By: Claude noreply@anthropic.com

https://claude.ai/code/session_01LeMSMf28QJFLTiQ25sVM3S

[github-actions]

Userscript Version Preview

Preview only — versions and CHANGELOGs are bumped automatically on merge to main, not in this PR. Manual bumps to a higher version are preserved.

Package	Base	New	Action
github-actions-grafana-jump	0.2.11	0.2.12	will-bump