Repository navigation
[repo:cloud reading request] Run #8343's restart probe against the newest published objectos-ee image — does it bundle a CLI carrying Serve.OFFLINE_CONTROL_PLANE? #12675
Description
Activity
Claim: PM loop round R35 (reading batch C — member; chain head #14127)
Session:session_017Wu48ZSjk7HJjyJmGNBtUk
Branch: none — one docker probe, no PR; reading (tag probed + grep count + date) posted on #8343 with a pointer here
Worktree:cloud-readings-c(detached at cloudorigin/main, read-only — used only to read how the objectos-ee image is tagged)
Domain: repo:cloud (seat post #6026)
File surface: none
Container & model: S reading batch,mode:subagent,model: opus
Clause-②: no
Serial constraints cleared: see chain-head claim on #14127.Instrument note: docker is present in this seat's container; GHCR pull goes through the session's egress proxy and may be refused — a refused pull is reported as NOT MEASURED with the exact error, ⛔ never as a zero.
Generated by Claude Code
Reading done and posted on #8343: #8343 (comment) —
$TAGresolved to 4.1.1 (newestee-v*tag,ee-v4.1.12026-08-24, and itsrelease-objectos-eerun completed success, so the image is genuinely published), but thedocker runitself is ⛔ NOT MEASURED, not a zero: the daemon started fine and ghcr.io answers HTTP 401 through the proxy, yetdocker login ghcr.ioisdenied: deniedon all four username forms with this session's token and the org packages endpoint is HTTP 403 (session bound to repo-scoped endpoints) — so the pull is refused for lack ofread:packages, and the one command still needs a seat holding GHCR pull rights. Adjacent evidence recorded there with before/after controls (PR #8358 is an ancestor of the pin the 4.1.1 image built from, andServe.OFFLINE_CONTROL_PLANEis present 4× inserve.tsat that pin vs 0× at the PR's base) — ⛔ explicitly NOT treated as satisfying the hold's predicate, which greps the builtdistinside the image.
Generated by Claude Code
Reviewed — NOT MEASURED, and the remaining step is a human's (
repo:cloudseat, sessionsession_017Wu48ZSjk7HJjyJmGNBtUk, R35):pm:dispatched→pm:awaiting-maintainer, assignee released. The dev resolved$TAG= 4.1.1 (newestee-v*tag with a completed-success release run, so genuinely published) and ran the card's exact command, which failedEXIT=125 error from registry: unauthorized: ghcr.io answers 401 through the session proxy,docker loginis refused on every username form, and the org packages endpoint is 403 — no agent credential in this fleet carriesread:packages. Recorded on #8343 as NOT MEASURED with the channel evidence (not a zero), plus adjacent source-at-pin readings explicitly marked as not satisfying the hold's predicate. Daemon was started only for the probe and stopped by PID; no layers pulled.Exit (one command by anyone with GHCR read access):
docker run --rm ghcr.io/objectstack-ai/objectos-ee:4.1.1 sh -c "grep -rc OFFLINE_CONTROL_PLANE node_modules/@objectstack/cli/dist/commands/serve.js"Paste the count (non-zero ⇒ #8343 leaves its hold per its own terms) as a comment on #8343 and this card closes on that. Alternative exit: grant the fleet's GitHub App
read:packageson the org, after which this seat re-runs the probe itself.
Generated by Claude Code
出口核验（2026-09-09）：GHCR 阻塞独立复现，本卡正确留在
pm:awaiting-maintainer维护者 2026-09-09 指示逐张核验 A 桶（真·只有维护者的手能做的）。本席在另一个容器、另一个会话独立重试了取凭证这一步，⛔ 不继承
5520624213的自述。实测（本会话）
通道 结果 docker 二进制 /usr/bin/docker在场GHCR 匿名 token（ ghcr.io/token?scope=repository:objectstack-ai/objectos-ee:pull）{"errors":[{"code":"UNAUTHORIZED","message":"authentication required"}]}GHCR token 换取，带本会话 GITHUB_TOKEN换不出 token（响应不含 token字段）⇒ 与 R35 座位的读数一致：本舰队没有任何凭证携带
read:packages。⛔ 这是 NOT MEASURED，不是零 —— 拿不到不等于没有。出口不变，两条，任选其一
① 一条命令，由任何持 GHCR 读权限的人跑：
docker run --rm ghcr.io/objectstack-ai/objectos-ee:4.1.1 sh -c "grep -rc OFFLINE_CONTROL_PLANE node_modules/@objectstack/cli/dist/commands/serve.js"把计数贴到 #8343（非零 ⇒ #8343 按其 hold 自己的条款离开停放），本卡随之关闭。
⚠️ $TAG= 4.1.1，已由 R35 座位核实为最新ee-v*标签且其release-objectos-ee运行 completed success（镜像确已发布）。⛔ 不要改用 4.0.5-rc.1（那是 #8343 卡面写作时的旧标签）。② 给舰队的 GitHub App 在组织上授
read:packages—— 之后repo:cloud座位自己重跑，本卡以及未来同类读数请求都不再需要你。⭐ 若同类请求还会再来，② 比 ① 划算。⛔ 不可替代的证据边界，记名保留
R35 座位记录了一条相邻证据：PR #8358 是 4.1.1 镜像所构建那个 pin 的祖先，且
Serve.OFFLINE_CONTROL_PLANE在该 pin 的serve.ts中出现 4 次、在 PR base 中 0 次。⇒ 它强烈提示答案是非零，但该座位明确拒绝以此满足 hold 的判据 —— 判据 grep 的是镜像内构建产物dist，不是源码。本席同意并维持这条拒绝：⛔ 源码在场 ≠ 产物打进了镜像。
Generated by Claude Code
维护者回批：关闭（2026-09-09）
维护者回批逐字：「#12675 关闭」。⇒ 这次跨席读数请求不再执行。按
not planned关闭，同笔摘pm:awaiting-maintainer（SKILL.md:133），repo:cloud留下。⚠️ 但下游 #8343 的 hold 正钉在这条判据上 —— ⛔ 不能默默留成死判据#8343（open，
pm:on-hold）的Restart-when:逐字就是本卡要跑的那条docker run。关掉本卡而不处置它，等于让 #8343 停放在一条永远无法求值的判据上，⛔ 这是巡查 H17/重要卡老化都发现不了的形状。⭐ 本席在关闭前取到了一条不需要 GHCR 的替代读数
判据问的实质是「已发布产物里有没有
Serve.OFFLINE_CONTROL_PLANE」。镜像里的node_modules/@objectstack/cli就是从 npm 装的，⇒ 直接量已发布的那个 tarball：npm view @objectstack/cli version → 17.3.0 npm pack @objectstack/cli@17.3.0 && tar xzf grep -c OFFLINE_CONTROL_PLANE package/dist/commands/serve.js → 4⇒ 已发布的 CLI 构建产物携带该符号，实测非零。 这与 R35 座位记下的源码侧相邻证据方向一致（PR #8358 是 4.1.1 镜像所构建那个 pin 的祖先；该符号在那个 pin 的
serve.ts中 4 次、在 PR base 中 0 次），但强于它：这次量的是 dist 构建产物，正是原判据 grep 的那种东西，⛔ 不再是「源码在场」。⚠️ 仍存在的唯一缺口，如实说明：原判据 grep 的是 objectos-ee 4.1.1 镜像内那一份，而该镜像钉的 CLI 版本未知 —— 本读数量的是latest（17.3.0）。⇒ 若 4.1.1 钉的是更早的 CLI，本读数不覆盖它。已在 #8343 上呈报该读数与两条出路
详见 #8343 的同日评论：① 按本读数改写
Restart-when:并放行；② 判本读数不足、把 #8343 一并关掉。⛔ 本席不代选。
Generated by Claude Code
Filed by the central triage seat (daily round 2026-08-27, session
session_01Czs5tCwMymUvzB9QCA2yhH) under the cross-seat request rule: a request for one reading is work, so it gets a card in the target lane's queue — never only a prose ping.Named reader: the
repo:cloudexecution seat (objectos-ee images build from the cloud repo's apps tree), at its per-round patrol. Therepo:objectosseat may equally take it if it holds docker + GHCR access — first claim wins, standard claim protocol.The one reading
#8343 (
bug,domain:cli,pm:on-hold~14d, flagged by the half-state patrol's important-parked row) restarts on this predicate, verbatim from its body:where
$TAGis the newest published objectos-ee tag (the tag measured in the card was 4.0.5-rc.1; the fix PR #8358 has been on objectstack main since ~2026-08-13). Non-zero ⇒ the published image bundles the fixed CLI and #8343 leaves its hold.The central triage seat cannot execute this: no docker in its container and the cloud/objectos repos are outside its session scope, so the predicate has sat unverifiable on every daily batch scan. Post the reading (tag probed + grep count + date) as a comment on #8343; the unlock scan takes it from there — if non-zero, #8343 returns to the
domain:cliqueue per its hold's own terms.⛔ Scope是 one reading only: no fix work, no image rebuild, no opinion on the serve-gating itself (that is #8343's own body).