fix(installer): the dashboard link follows CLIENT_ENV on the bash side too (backend#2849)

[shujaatTracebloc]

The other half of the contract

Bugbot on #931: Get-TraceblocDashboardUrl fixed the Windows half, and the bash twins still hardcoded https://ai.tracebloc.io at ten sites across install-client-helm.sh and summary.sh — while _backend_url directly above them was correctly env-aware.

So a CLIENT_ENV=dev install on Linux or macOS still sends the operator to the production dashboard for credentials that dev-api then rejects. Same defect, other platform.

It's also exactly the rule this week added to .cursor/BUGBOT.md — "a fix that landed in one twin only" — catching my own change one PR later.

The fix

_dashboard_url mirrors the PowerShell helper:

CLIENT_ENV	dashboard
dev / development	https://dev.tracebloc.io
staging / stg	https://stg.tracebloc.io
production / unset / unknown	https://ai.tracebloc.io

The hosts are the backend's own per-environment settings, not a guess — DEVICE_VERIFICATION_URI / RESET_PASSWORD_URL in xraybackend/settings/{dev,stg,prod}.py. And it uses the same tb_client_env alias reduction and the same unknown→prod fallback as _backend_url, so the two cannot disagree about which environment an install belongs to.

One thing worth stating

My first verification used a throwaway tb_client_env stub with ${1,,}, which silently fails on macOS bash 3.2 and made every case look like prod. The harness was wrong, not the code — re-verified against the real function. The helper itself is bash-3.2 clean: no case conversion, no ${var,,}, which matters because install.sh runs on macOS.

Evidence

• 7 bats guards, including one that pairs _dashboard_url with _backend_url per environment — the defect was those two disagreeing, so asserting each alone would miss the next split — and one asserting no live link in either file carries a hardcoded production path.
• 247 bats pass; bats-hygiene clean (the repo's own check that every assertion actually enforces, rather than a bare expression that always succeeds).
• shellcheck --severity=error clean on both files; check-style.sh clean; manifest regenerated.

Part of tracebloc/backend#2849.

🤖 Generated with Claude Code

---

Note

Low Risk
Installer messaging and URL construction only; no auth, credential, or deployment logic changes beyond pointing users at the correct dashboard host.

Overview
Fixes env-aware dashboard links on Linux/macOS so operators on CLIENT_ENV=dev or staging are no longer sent to the production dashboard (ai.tracebloc.io) while API calls go to dev-api / stg-api — the same mismatch the PowerShell helper already fixed.

Adds _dashboard_url in common.sh (bash twin of Get-TraceblocDashboardUrl): maps dev / stg / prod (via tb_client_env, same aliases and unknown→prod fallback as _backend_url) to dev.tracebloc.io, stg.tracebloc.io, and ai.tracebloc.io, with an optional path segment (default clients).

Replaces ten hardcoded production URLs in install-client-helm.sh (credential errors, prompts) and summary.sh (connected/starting/bad_creds copy, including my-use-cases). Placing the helper in common.sh ensures summary.sh gets it when loaded standalone (e.g. bats/catalog), avoiding empty dashboard links from implicit load order.

Tests: new common.bats coverage for env mapping, no hardcoded live links, standalone summary.sh reachability; copy-catalog.bats pins CLIENT_ENV=prod for golden stability; install-client-helm.bats asserts _dashboard_url agrees with _backend_url per environment. Manifest checksums updated.

^{Reviewed by Cursor Bugbot for commit b220610. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

The bats failure is real, and it's the same defect class this PR exists to close — one layer down.

scripts/lib/summary.sh calls _dashboard_url at four sites — :191, :196, :233, :240 — and defines it nowhere, and sources nothing. The helper lives only in install-client-helm.sh:878. The two are sibling libraries; install-client-helm.sh never sources summary.sh, and the only mentions of it there are comments.

So summary.sh now depends on load order that nothing enforces. The suite caught it exactly:

scripts/tests/copy-catalog.bats:147
  emit_outcomes | check_golden 01-outcomes.golden' failed
  - See it on your dashboard:  https://ai.tracebloc.io/clients
  + .../scripts/tests/../lib/summary.sh: line 191: _dashboard_url: command not found
  +     See it on your dashboard:

scripts/tests/summary.bats:97
  [[ "$output" == *"my-use-cases"* ]] || return 1

Note what the golden diff actually shows: the URL doesn't fall back to production, it renders empty. Before this change a CLIENT_ENV=dev operator got a working link to the wrong environment. On any path where summary.sh is loaded without install-client-helm.sh in the same shell, they now get See it on your dashboard: followed by nothing — and the "Create a use case" line loses its link too. That's a worse failure than the one being fixed, because a wrong link is recoverable by the reader and a missing one isn't.

I want to be exact about scope: I confirmed the standalone-load path is broken (that's what summary.bats does — load_lib summary.sh), and I did not establish whether every production entry path happens to source install-client-helm.sh first. It may well be that the shipped installer always does, in which case users are fine today and only the suite is red. That doesn't change the fix, and it doesn't make the current state safe: a library that silently requires a sibling to have been sourced first is one refactor away from shipping a blank URL, with nothing to catch it except the tests that are red right now.

The fix is one decision. _dashboard_url belongs in scripts/lib/common.sh — the shared library both files already rely on, and where tb_client_env (which your helper calls) would naturally sit. That makes it available to both twins by construction rather than by load order. Sourcing it from summary.sh would also work but re-creates the coupling in the other direction.

On the change itself, which I like. Ten hardcoded https://ai.tracebloc.io sites across the bash twins, while _backend_url directly above them was already env-aware, is a genuine and well-evidenced gap — a CLIENT_ENV=dev install on Linux or macOS really was sending operators to prod for credentials dev-api rejects. The table in the description is the right way to present it, _dashboard_url mirrors the PowerShell helper's shape, and defaulting path to clients keeps the four call sites terse without hiding anything.

I checked the one substitution that looked risky — $(_dashboard_url)) in _no_interactive_creds_die, where the second paren is the literal one closing "(find them at …)". That's correct: the default path makes it …/clients, and the sentence closes properly.

And the framing is right — catching "a fix that landed in one twin only" one PR after adding that rule to .cursor/BUGBOT.md is the rule working. Worth noting the irony that the fix reproduces the same shape between install-client-helm.sh and summary.sh; putting the helper in common.sh closes both.

Requesting changes on the undefined function. Everything else here is ready to go.

[LukasWodka]

The fix is right, and I verified the chain rather than the commit message. _dashboard_url is now defined once, in common.sh:

scripts/lib/common.sh                 1 definition
scripts/lib/install-client-helm.sh    0 definitions, 6 references
scripts/lib/summary.sh                0 definitions, 4 references

And the thing that actually makes that work — which I'd flagged as unverified in my last review — checks out in both directions:

• Tests: scripts/tests/test_helper.bash:10-16, load_lib() sources common.sh unconditionally before the named lib. So load_lib summary.sh now has the helper in scope; that is exactly the path that was failing.
• Runtime: install-client-helm.sh:809-810 records the house idiom — "install-k8s.sh sources common.sh before this file, so it's in scope" — the same guarantee _strip_paste_garbage already relies on.

So the dependency is on the shared library both siblings already require, not on load order between two peers. That's the structural version of the fix rather than a patch, and moving the tests with it (install-client-helm.bats −54, common.bats +80) puts them where the next person will look.

Two things now block it, neither of them mine.

It has picked up a merge conflict. mergeable=CONFLICTING, ms=DIRTY at 1c6bd3b3 — it was MERGEABLE at 776a30cd, so this arrived with the push or with something that landed on develop in the last few minutes. Worth knowing straight away since you're mid-flow; six other client PRs went conflicting in the same window earlier, so this looks like the shared cause rather than anything in your diff.

CI hasn't finished — Cursor Bugbot still pending, and the rest of the suite is mid-rebuild after the push, so I can't yet confirm copy-catalog.bats and summary.bats have gone green. Those two are the ones that named the defect, so they're the evidence I want.

Leaving my change-request in place for now, but only as bookkeeping: the objection it was raised for is met. I'll clear it the moment the rebase lands and the suite is green — no further review needed from your side, and nothing new from me.

[LukasWodka]

Careful — this reads green and isn't. The only check on 1c6bd3b3 is Cursor Bugbot, and it is skipping:

skipping  Cursor Bugbot

That is the entire check list. bats (bash unit, mocked) and Unit tests never ran, so the rollup says SUCCESS by absence rather than by evidence — a skip isn't a failure. Almost certainly downstream of the conflict: it is still CONFLICTING / DIRTY, and workflows generally don't fire when the merge commit can't be computed. Rebase first and the suite will actually run; until then there is no result on the two files that named the defect.

And Bugbot has found something real in the fix — worth folding into the same push. summary.sh:196:

print_summary now emits _dashboard_url, so the 01-outcomes golden varies with CLIENT_ENV, but copy-catalog.bats setup() never pins or unsets that variable.

That is correct and it is the sharper half of the problem. The golden used to be a constant string; routing it through _dashboard_url makes it a function of the developer's environment. Two consequences, and the second is worse:

• A developer with CLIENT_ENV=dev exported in their shell fails copy-catalog on an unmodified tree — a test that fails based on who runs it.
• If someone "fixes" that by regenerating the golden, they bake https://dev.tracebloc.io into the committed catalog, and the prod copy silently becomes wrong. The test would then be green and the artifact wrong, which is the worse of the two failure modes.

setup() pinning CLIENT_ENV=prod (or unsetting it) is the fix, and it belongs with this change rather than as a follow-up — the environment-dependence is something this PR introduces.

No change to my position, and nothing new required of you beyond those two: rebase, pin the variable in copy-catalog.bats setup(). The common.sh relocation itself I have already verified and I am happy with it. I will clear the change-request once the rebase lands and I can see the two suites actually pass rather than skip.

[shujaatTracebloc]

@LukasWodka — you were right on every point, and the diagnosis was sharper than the symptom. Fixed in 1c6bd3b.

_dashboard_url now lives in common.sh, which is the decision you named. I confirmed why it is the right one rather than taking it on faith: install-k8s.sh sources common.sh first, and the bats load_lib sources it unconditionally before any named lib — so both twins get the helper by construction, and tb_client_env (which it calls) already lives there. Sourcing summary.sh from the helm lib would have re-created the coupling in the other direction, as you said.

Your note about what the golden diff actually showed is the part that mattered. I had assumed a missing helper would fall back to production; it renders empty — See it on your dashboard: followed by nothing, and the "Create a use case" line losing its link. You are right that this is worse than the bug being fixed: a wrong link a reader can recover from and a missing one they cannot. I would have shipped a regression while fixing a defect.

And on scope, matching your care about it: I did not establish either whether every production entry path sources install-client-helm.sh first. It does not change the fix, and common.sh makes the question moot rather than answered — which is the better outcome.

Two new guards for the defect itself, in common.bats where the helper now lives:

• _dashboard_url is reachable from summary.sh loaded standalone (the exact path summary.bats takes).
• No lib under scripts/lib defines it except common.sh — so a future move back into a sibling is caught rather than discovered.

The _backend_url pairing test stays in install-client-helm.bats: it is the only assertion needing both helpers in scope, and the defect it guards is those two disagreeing.

summary.bats and copy-catalog.bats are green again; bats-hygiene clean; shellcheck --severity=error clean on all three libs.

On the irony you flagged — the fix reproducing the one-twin shape between install-client-helm.sh and summary.sh while fixing it between bash and PowerShell — that is now written into the mutation registry on client#931 as its own entry, so the next occurrence is caught by a test rather than by a reviewer.

[shujaatTracebloc]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

1 issue from previous review remains unresolved.

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 1c6bd3b. Configure here.}

[shujaatTracebloc]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit b445b85. Configure here.}

[LukasWodka]

The blocker is closed, and I checked it by running it rather than by reading the diff.

_dashboard_url now has exactly one definition, in the right place. common.sh:73, and zero in install-client-helm.sh — the six mentions left there are call sites. So the helper is no longer a thing one sibling owns and the other borrows.

The "sourced first by construction" claim in your comment is true — I verified all three paths rather than taking it on the comment's word, since that claim is the whole fix:

scripts/install-k8s.sh:65    source "${LIB_DIR}/common.sh"     <- first, unconditional
scripts/install-k8s.sh:111   source "${LIB_DIR}/summary.sh"
scripts/install.sh:274       "scripts/lib/common.sh"           <- fetched before
scripts/install.sh:289       "scripts/lib/summary.sh"
scripts/tests/test_helper.bash:11   source "${LIB_DIR}/common.sh"   <- unconditional in load_lib

Production entry, remote bootstrap, and the test harness all load common.sh before anything that calls into it. That is the difference between "works today" and "works because it cannot not work".

Exercised the standalone path — the one that was command not found:

CLIENT_ENV=prod     https://ai.tracebloc.io/clients   | .../my-use-cases | https://ai.tracebloc.io
CLIENT_ENV=dev      https://dev.tracebloc.io/clients  | .../my-use-cases | https://dev.tracebloc.io
CLIENT_ENV=stg      https://stg.tracebloc.io/clients  | .../my-use-cases | https://stg.tracebloc.io
CLIENT_ENV=staging  https://stg.tracebloc.io/clients  | .../my-use-cases | https://stg.tracebloc.io
CLIENT_ENV=bogus    https://ai.tracebloc.io/clients   | .../my-use-cases | https://ai.tracebloc.io
CLIENT_ENV=<empty>  https://ai.tracebloc.io/clients   | .../my-use-cases | https://ai.tracebloc.io

sourcing common.sh + summary.sh and nothing else. Two things worth naming: the staging alias reduces to stg through tb_client_env, so the vocabulary gap that has bitten this repo before is covered by reuse rather than by a second case statement; and ${1-clients} (not ${1:-clients}) is what makes _dashboard_url "" return the bare host, which the four call sites don't use but the docstring promises. Deliberate, and I'd keep the comment that says so.

Mutation-proved it, since a passing check that would pass anyway is worth nothing. Deleting the definition from common.sh — anchor confirmed applied, occurrences 1 → 0 — brings back exactly bash: _dashboard_url: command not found; restoring gives https://dev.tracebloc.io/clients again. The fix is load-bearing.

And the Bugbot pin landed well. copy-catalog.bats setup() now exports CLIENT_ENV=prod with a comment that carries the reproduction (CLIENT_ENV=dev bats copy-catalog.bats → not ok 2 ... 01-outcomes). That is the right shape: the golden now depends on an environment variable, so the suite says which one instead of inheriting whatever the operator's shell had.

Not approving yet, and this time it's for a real reason rather than a formality. The develop merge in b220610c re-queued the whole suite — 43 checks pending, including bats (bash unit, mocked), which is the one that was red and is the actual evidence for everything above. My local run is a good signal, not the artifact. It's MERGEABLE, the conflict is gone, and there are zero unresolved threads, so the moment those land I'll flip this to an approval. Nothing further needed from you.

Good fix — you moved it to common.sh rather than patching the symptom with a source, which is the version that doesn't come back.

[LukasWodka]

CI has settled and the suite that mattered actually ran. Approving at b220610c.

bats (bash unit, mocked) — pass, 4m30s. That is the one I was waiting for and the reason I held rather than approving on my local run: it is the suite that was red on _dashboard_url: command not found, and a green elapsed run is the artifact. Worth being explicit that it is not a skip — this repo has bitten us before with a rollup reading SUCCESS when the only thing in it declined to run.

Full gate at this head: 47 pass, 0 failing, 0 pending, 4 skipping (E2E last-mile journey, Full seal suite vs dev, quality / format, quality / ruff — none of them cover this diff), MERGEABLE, zero unresolved threads, and the only standing review was my own change-request, which this clears.

Cursor Bugbot and bugbot / review both ran to completion and passed, so the CLIENT_ENV pin in copy-catalog.bats settled its own finding rather than leaving it open.

Everything I verified last pass stands: one definition in common.sh:73, zero in install-client-helm.sh, common.sh sourced first on all three load paths (install-k8s.sh:65, install.sh:274, test_helper.bash:11), all six CLIENT_ENV values resolving correctly including the staging → stg alias, and the mutation proof showing the definition is load-bearing.

Thanks for the rebase and for taking the helper to common.sh rather than papering over it with a source — that is the version that doesn't come back in six months.

[LukasWodka]

/fr-pass

Functional review on staging — passed, with direct evidence.

Journey (tier A), staging · amd64, run 33494337123 — green end to end, every leg:

install via the real installer → client components healthy → CLI installed from its signed release and signed in → dataset ingested for every task type → use case published → model trained and the leaderboard read.

The train leg, which is the one that matters:

experiment echi0zyk (pk 4041) started
experiment echi0zyk: COMPLETED (terminal, 29 poll(s))
inference submit: submitted for inference on cycle no 2
leaderboard: found after 6 poll(s), running_score=0.9, cycle=2
submissions: our run is on the board (accuracy=0.9 loss=0.3515 captured=True); 1 row(s) total

This repo's change is on the path that run exercised, so this is functional evidence rather than an inference from code review.

Two things stated rather than glossed:

• The run is against the deployed code. Backend f991c788 was helm upgraded into staging at 09:50:19Z and this journey started at 09:50:46Z. A separate journey (33493727497) sits red from 09:43:42 — seven minutes before that deploy — so it exercised the previous image and is not evidence about this promotion.
• e2e-test-agent did not ship this hop (blocked by a Bugbot High, e2e-test-agent#368). So this is yesterday's agent, and the run does not exercise e2e's own unshipped changes. It exercises the platform, which is what this card needs.