remote hub: four P2 follow-ups left open after the stack merged

[lidge-jun]

What happened

The remote-hub stack (#2771 → #2789) merged into dev on 2026-09-01. Four P2 review threads were assigned to phases but resolved as follow-up work rather than blocking the merge, and this issue carries them so they do not evaporate with the closed PRs.

Source: devlog/_plan/260901_remote_hub_restack/003_review_thread_ledger.md and 121_open_threads_after_merge.md.

The four

T2 — connected GUI has no authenticated models path. /v1/models goes to the data plane, so a GUI attached to a connected runtime cannot list models over the management plane. Origin thread: 060_phase4_two_plane.md:348, owned by phase 4 (#2781).

T3 — GUI health endpoint is not preserved through the management ingress. Origin thread: 070_phase5_deploy.md:164, owned by phase 5 (#2786).

T19 — the extended readiness response is undocumented. /readyz gained protocol negotiation metadata in phase 1; docs-site/src/content/docs/en/cli/lifecycle.md still describes the old shape. Origin: src/server/index.ts:1013, owned by phase 1 (#2772).

T21 — three new config keys are undocumented. hub.managementPublicOrigin, remoteGui.allowedTailscaleUsers, and remoteGui.allowInsecureHttp ship without docs-site coverage. Origin: src/types/config.ts:251, owned by phase 2 (#2776).

Why they were not merge blockers

None of them regress existing behavior. T2 and T3 are gaps in a surface that is opt-in and off by default for a standalone install; T19 and T21 are documentation debt for configuration that already defaults to the previous behavior. The P1 threads (T1, T20, T22, T25, T26, T31) were all closed with code in their owning phase and landed with those phases.

Separately: a flake worth watching

ocx launcher graceful shutdown > SIGINT to the launcher tears down the Bun proxy and restores Codex config (no orphan) (tests/shutdown-launcher.test.ts) hit a 20069ms watchdog timeout on the #2789 macOS job. It passed on rerun and the stack does not touch that file, so it is a dev-side flake rather than stack fallout. Not investigated.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[Ingwannu]

I rechecked all four items against current dev; the implementation scope is smaller than the carry issue states.

• T2 is already satisfied. The connected GUI discovers a shared management target, bootstraps an authenticated GUI session, and every model consumer (Models, Dashboard, Combos, and Routing Profiles) reads GET /api/models through that shared base. None of those GUI paths depends on data-plane /v1/models.
• T3 is real, but only at one caller. App-level liveness correctly uses the local machine plane. The remaining broken caller is MemoryObservabilityCard's post-restart reconnect loop: Dashboard passes the shared management base, then the loop requests ${apiBase}/healthz. The management ingress intentionally and correctly rejects /healthz. I will keep that deny boundary and poll authenticated /api/system/memory instead; the restart action is shown only when that route is already supported, and its PID is the value the loop needs.
• T19 is real. The lifecycle docs still list only {service, version, uptime, pid, port, status}, while /readyz now also returns protocol, minimumClientProtocol, and managementUrl. I will update the canonical page and its existing translated counterparts.
• T21 is partly stale. hub.managementPublicOrigin and remoteGui.allowedTailscaleUsers are already covered by both the Remote Hub guide and server configuration reference. remoteGui.allowInsecureHttp is retained only so old strict-schema configs still load; it is a deprecated no-op and cannot reopen plaintext pairing. I will document that retirement rather than present it as an active switch.

The patch will therefore change only the authenticated restart reconnect probe and the still-inaccurate documentation. It will not expose /healthz or /readyz on the management ingress and will not add another model endpoint.

[Ingwannu]

Incremental correction while tracing the concrete GUI consumers: there are two shared-plane /healthz callers, not one.

1. fetchDashboardOverview pairs ${apiBase}/healthz with /api/providers.
2. MemoryObservabilityCard uses ${apiBase}/healthz during post-restart PID replacement polling.

Both receive the shared management base in a connected GUI, so both fail through the intentionally default-deny management ingress. The app-shell liveness poll is separate and correctly stays on the local machine base.

The narrow fix should therefore add one authenticated, scalar-only GET /api/system/health management route and move those two shared-plane callers to it. /healthz and /readyz remain denied on the management listener. I will add a live management-ingress regression that proves the new API works with a GUI session while raw /healthz remains 404 there.

[Ingwannu]

The corrected follow-up patch is now in #3168.

The live ingress regression proves authenticated /api/system/health works while raw /healthz remains 404 on the same management listener. Connected Dashboard status and restart recovery use the new API, /api/models remains the existing authenticated model path, all eight lifecycle/config locale pairs are synchronized, GUI lint/build passes, and the docs build completes all 409 pages. I am leaving the issue open until the GUI change is reviewed, exact-head CI is green, and the PR is merged.

[lidge-jun]

리뷰 · 우선순위 72 / 80

설명

이 이슈는 remote hub restack이 dev에 이미 들어간 뒤에 남은 P2 네 가닥을 한곳에 모아 둔 추적 이슈입니다. 지금 checkout HEAD는 2f2629f27 입니다. 마지막 머지는 #3165 skill 문서이고, 그 앞줄에 #3162/#3161/#3160/#3159 closeout 문서가 있습니다. 설계 #2771과 단계 p1–p6(#2772/#2776/#2777/#2781/#2786/#2789)은 이미 HEAD에 있습니다. 패키지는 2.40.0입니다. 태그 v2.39.0 / v2.39.0-preview.20260901 도 origin에 있습니다. 그래서 이 이슈를 "아직 안 올라온 허브 스택"으로 읽으면 안 됩니다. 이미 올라온 표면 위의 후속입니다.

본문이 말하는 네 가닥은 T2, T3, T19, T21입니다. T2는 연결된 GUI가 관리 평면으로 모델 목록을 못 받는다는 이야기였습니다. /v1/models 는 데이터 평면이라, 페어링된 런타임에 붙은 GUI가 관리 자격으로 모델을 못 읽습니다. T3는 GUI가 쓰는 health가 관리 ingress에서 막힌다는 이야기입니다. T19는 /readyz 가 프로토콜 협상 필드를 냈는데 lifecycle 문서가 예전 모양만 적었다는 문서 부채입니다. T21은 hub.managementPublicOrigin, remoteGui.allowedTailscaleUsers, remoteGui.allowInsecureHttp 문서 공백입니다. 출처는 devlog/_plan/260901_remote_hub_restack/003_review_thread_ledger.md 와 121_open_threads_after_merge.md 입니다. 그 폴더는 지금 checkout에 실제로 있습니다.

왜 머지 블로커가 아니었는지도 본문이 분명히 적습니다. T2/T3는 기본 단독 설치에서 꺼져 있는 opt-in 표면의 빈자리이고, T19/T21은 기본값이 예전과 같은 설정의 문서 빚입니다. P1 스레드(T1, T20, T22, T25, T26, T31)는 각 단계 코드와 함께 이미 닫혔습니다. 별도로 tests/shutdown-launcher.test.ts 의 SIGINT 복원 케이스가 #2789 macOS job에서 20초 감시 시간을 넘긴 플래크가 있습니다. 스택이 그 파일을 건드리지 않았고 재실행에 통과했으므로, 이 이슈의 네 가닥과 묶지 않는 편이 맞습니다.

같은 날 열린 PR #3168 이 이 이슈를 Closes 로 걸었습니다. 그 PR 본문은 범위를 다시 짚습니다. T2는 코드가 필요 없었습니다. 연결된 모델 소비자는 이미 인증된 공유 평면 GET /api/models 를 씁니다. T3는 Dashboard overview와 재시작 뒤 PID 폴링 두 호출자가 있었고, 둘 다 인증된 management health로 옮깁니다. T19는 lifecycle 문서에 protocol, minimumClientProtocol, managementUrl 을 넣습니다. T21은 allowInsecureHttp 만 폐기된 no-op으로 밝히고, 나머지 두 키는 이미 문서에 있었습니다. 지금 dev 방향이 remote hub 후속 연마이므로, 이 추적 이슈의 점수는 높게 둡니다. types.ts/config.ts 분할 캠페인과는 무관합니다.

점수는 72입니다. 스택은 이미 올라와 있고, 남은 것은 연결된 GUI가 재시작·상태 폴링에서 관리 평면을 쓸 수 있게 하는 후속과 문서입니다. #3168이 그 대부분을 가져왔으므로, 이 이슈는 PR 리뷰·머지와 함께 닫는 쪽이 맞습니다.

경로 issue #3158 T2 - 본문은 "인증된 models 경로 없음"으로 적었지만, #3168은 연결된 소비자가 이미 GET /api/models 를 쓴다고 정정합니다. 이슈만 보면 T2를 새로 구현해야 한다고 오해할 수 있습니다
경로 issue #3158 T21 - 세 키를 한꺼번에 문서 공백으로 적었지만, #3168 정정에 따르면 managementPublicOrigin 과 allowedTailscaleUsers 는 이미 문서에 있고 allowInsecureHttp 만 폐기 설명이 비었습니다
경로 docs-site/src/content/docs/reference/cli/lifecycle.md - HEAD에는 /readyz 설명이 있지만, 이슈가 지적한 protocol 협상 세 필드는 #3168 문서 diff에서야 채워집니다
경로 tests/shutdown-launcher.test.ts - 본문이 별도 플래크로 적었습니다. 이 이슈 네 가닥과 묶으면 후속 범위가 커집니다
경로 PR #3168 - Closes #3158 을 걸었고 MERGEABLE 입니다. 이 이슈를 따로 설계 이슈로 남겨 두면 열린 숫자만 부풉니다

메인테이너의 판단이 필요한 지점

• #3168을 머지하면 이 이슈를 Closes로 같이 닫을지. T2 정정(코드 불필요)을 이슈 본문에도 한 줄 남길지
• shutdown-launcher 플래크를 별 이슈로 떼어 낼지, 이 이슈 범위 밖으로만 둘지
• remote hub 후속 연마에서 T3 health 경로가 보안 리뷰 대상인지. management 인증 health는 자격 증명 평면입니다

너의 추천
#3168 리뷰를 마치고 머지한 뒤 이 이슈를 닫습니다. 지금 HEAD에서 remote hub는 이미 켜져 있으므로, 이 이슈를 스택 재개로 읽지 마십시오. T2는 정정된 대로 새 엔드포인트가 아니라 기존 /api/models 확인입니다. T3/T19/T21은 #3168이 가져옵니다. shutdown-launcher 플래크는 별 추적만 하고 이 이슈에 묶지 않습니다. 라벨은 이 댓글에서 바꾸지 않습니다.

이 댓글은 grok-bot이 작성했습니다