Measured during #4472 (PR #4480's copy census). Observation-class: no user-visible defect today; no fix proposed here.
What
packages/app-shell/src/console/ai/AiChatPage.tsx:986 builds publicShareBase by reading the injected base-href tag itself and assembling ${origin}/_console/s — a third, independent implementation of the console-mount resolution that resolveConsoleUrl / resolveRootUrl (packages/app-shell/src/console/organizations/resolveHomeUrl.ts) already centralize.
Measured in the #4472 worktree: its output is correct for the deployment shapes tested — this is not #4472's defect (that one rebuilt from BASE_URL and produced the trailing-dot host).
Why it is worth recording
#4472 just deleted two local URL builders on the one-resolver principle; this is the surviving sibling. A correct-today duplicate of a centralized mechanism is exactly the shape that drifts: the next change to mount semantics (new deployment shape, base-href format change) updates the helper and misses the copy. Folding it into resolveConsoleUrl (the /s public-share path may need a parameter or a sibling helper — measure at fix time) removes the mechanism duplication.
Also for the record, from the same census: apps/console/src/utils/consoleBase.ts reads BASE_URL deliberately, never concatenates an origin, and is documented + tested — ruled not-in-family. The API-base display sites (ObjectApiPanel etc.) are not under the console mount — not in family.
Repo-wide test trap recorded in PR #4480 (relevant to whoever fixes this)
vi.stubEnv('BASE_URL', …) silently does nothing against the (import.meta as any).env?.BASE_URL spelling — Vite inlines bare import.meta.env at transform time, so such a test is permanently green. Write pins against the injected base-href mechanism instead.
Filed unassigned for triage.
Generated by Claude Code
Measured during #4472 (PR #4480's copy census). Observation-class: no user-visible defect today; no fix proposed here.
What
packages/app-shell/src/console/ai/AiChatPage.tsx:986buildspublicShareBaseby reading the injected base-href tag itself and assembling${origin}/_console/s— a third, independent implementation of the console-mount resolution thatresolveConsoleUrl/resolveRootUrl(packages/app-shell/src/console/organizations/resolveHomeUrl.ts) already centralize.Measured in the #4472 worktree: its output is correct for the deployment shapes tested — this is not #4472's defect (that one rebuilt from
BASE_URLand produced the trailing-dot host).Why it is worth recording
#4472 just deleted two local URL builders on the one-resolver principle; this is the surviving sibling. A correct-today duplicate of a centralized mechanism is exactly the shape that drifts: the next change to mount semantics (new deployment shape, base-href format change) updates the helper and misses the copy. Folding it into
resolveConsoleUrl(the/spublic-share path may need a parameter or a sibling helper — measure at fix time) removes the mechanism duplication.Also for the record, from the same census:
apps/console/src/utils/consoleBase.tsreadsBASE_URLdeliberately, never concatenates an origin, and is documented + tested — ruled not-in-family. The API-base display sites (ObjectApiPanel etc.) are not under the console mount — not in family.Repo-wide test trap recorded in PR #4480 (relevant to whoever fixes this)
vi.stubEnv('BASE_URL', …)silently does nothing against the(import.meta as any).env?.BASE_URLspelling — Vite inlines bareimport.meta.envat transform time, so such a test is permanently green. Write pins against the injected base-href mechanism instead.Filed unassigned for triage.
Generated by Claude Code