Repository navigation
os login --json 与 os cloud login --json 现在对同一件事给出相反的契约 —— 一个发 NDJSON 事件流,一个把设备授权 URL 完全吞掉 #6730
Description
Activity
Maintainer ruling (2026-08-08): Route 1 — extend the #6531 NDJSON ruling to os cloud login --json.
Both device-flow login commands carry the same contract: an NDJSON event stream of compact single-line JSON documents, with the verification-URL event emitted before authorization completes. Reuse PR #6727's emitRecord() outlet and its e2e pinning pattern, and extend the same documented-exception blocks (--help, cli.mdx, authentication.mdx). This is a user-visible breaking change to cloud login's stdout — the changeset must say so.
Sequencing: blocked by PR #6727 (the os login NDJSON implementation) — land after it merges so the shared outlet exists to reuse. A Blocked-by line is added to the body; pm:blocked comes off when #6727 merges (unlock sweep or cli lane).
Rationale (three-axis review):
- Business: the
os login --json(device flow) writes TWO JSON documents to stdout, so the whole stream is unparseable #6531 rationale — automation's core value is getting the verification URL before authorization — applies verbatim to cloud login, which today swallows the URL entirely. Same audience, strictly worse behavior. - Long-term: route 2 would institutionalize two meanings of --json inside one CLI; route 3 would reverse a same-day ruling with zero new evidence.
- AI-error containment: an AI script author learns the NDJSON contract from the os login docs and applies it to cloud login — the divergence is a trap; route 1 removes it.
Also fixed in this pass: the card carried pm:queue and needs-user-decision simultaneously (a half-state the label state machine forbids); resolved to pm:queue + pm:blocked.
State: needs-user-decision removed; pm:queue + pm:blocked (Blocked-by: #6727) — cli lane.
Maintainer directive (verbatim, covering this batch of 6 inbox cards): 「接受你的建议」. Recorded by PM session session_01JaVVMrSxt7Tgi1uwEuDtH7.
Generated by Claude Code
- Business: the
维护者裁定(2026-08-08,cli 席存档):取岔口 1 ——
os cloud login --json也改 NDJSON,与os login --json同一契约。needs-user-decision摘除,卡转可派。理由与 #6531 的裁定同源:device flow 在自动化场景的价值就是让消费者在用户授权前拿到 verification URL。
os cloud login --json今天传silent: flags.json,格式上无可指摘(单文档、可直接JSON.parse),但代价是那个 URL 从不交给自动化 —— 也就是把 device flow 在脚本里最有用的那一半关掉了。同一个 CLI 里两条面向同一受众的命令给相反答案,是未经裁定的分歧,不是有意为之的差异。实施要求(与 #6531 / PR #6727 保持同形,不得另起一套):
- 该命令的全部
--json写点统一走单一写出口,一行一份紧凑文档 —— 不只是 device flow 那两处。os login --json(device flow) writes TWO JSON documents to stdout, so the whole stream is unparseable #6531 的经验:失败记录是在 device 记录之后才可能到达的,漏掉它就在消费者最没法恢复的那条路径上重建了两文档流。 - 声明式例外必须写进文档:该命令的
--help文案 + 相应文档页,写明「本命令的--json是 NDJSON,逐行解析」。一个没写进文档的例外和原 bug 是同一类伤害。 - 破坏性变化如实披露:
os cloud login --json今天的单文档形状是可用的,可能已有消费者。changeset 正文必须写明 wire 形状变化,不得静默过去。 - 复现纪律照抄 fix(cli):
os login --json声明为 NDJSON 事件流，每行一份可解析文档 (#6531) #6727:该 device flow 同样只在process.stdin.isTTY为真时才走,管道 stdin 到不了那些写点 —— 需要 PTY(script(1))驱动;PR fix(cli):os login --json声明为 NDJSON 事件流，每行一份可解析文档 (#6531) #6727 已在仓内落下第一个 PTY 驱动测试,可直接借用其惯用法。
Generated by Claude Code
- 该命令的全部
CLAIM — session
session_017uFVNMmTxLpmfQYiuKM1Yx, branchclaude/issue-6730-cloud-login-json-ndjson.实施 2026-08-08 维护者裁定(comment 5226489062)取岔口 1:
os cloud login --json对齐os login --json的 NDJSON 契约,照抄 PR #6727 的单一写出口 / 声明式例外文档 / PTY 驱动 e2e 惯用法。先在未修改的origin/main上实测今天的单文档形状与「verification URL 从不到达 stdout」这一前提。⛔ 不碰
packages/cli/src/commands/login.ts(#6531 / PR #6727 的地盘)。
Generated by Claude Code
续作说明(同一 session
session_017uFVNMmTxLpmfQYiuKM1Yx,同一分支claude/issue-6730-cloud-login-json-ndjson) —— 前一轮在写 changeset 时撞上 API 配额中断,盘上工作完好(3 个本地提交,工作树干净,未推送)。本轮接续:先把期间前进的
origin/main合并进来,把前一轮的全部测量视为作废,在合并后的树上重跑整条验证链(前提复测 → 正反向验证 → lint/typecheck/CLI 全量 →check:*全套 → 字节自查),然后推分支开草稿 PR。反向验证的预测在前一轮动手之前就已落盘,本轮沿用、不重写。
Generated by Claude Code
- added a commit that references this issue
on Aug 16, 2026 - added a commit that references this issue
on Aug 17, 2026
分诊卡,由
domain:cli席在 #6531(PR #6727)验收时立。未认领,未评级。 记录事实与一处需要裁定的分岔,不预设处置。事实
#6531 的维护者裁定(2026-08-08,#6531 comment 5226101978)把
os login --json定为 NDJSON 事件流,理由写得很明确:device flow 在自动化场景的核心价值,是让消费者在用户授权前就拿到verification_uri。PR #6727 据此实现,并把这个例外写进了--help、content/docs/deployment/cli.mdx与content/docs/permissions/authentication.mdx。同一个仓里的姊妹命令走的是相反的路:
packages/cli/src/commands/cloud/login.ts——os cloud login --json把silent: flags.json传进它自己的 device flow,于是只发一份文档。这不是缺陷:它的 stdout 是单文档、可被
JSON.parse直接读,格式上完全正确。代价在别处 —— 它从不把 verification URL 交给自动化消费者,也就是 #6531 裁定认定为 device flow 全部意义所在的那个东西。发现者(#6531 的实施 agent)因此没有把它当缺陷立单,而是交回 PM 分诊。为什么值得记
两条命令现在对「
--json下的 device flow 应该给消费者什么」给出可见的不同答案,而它们面向的是同一类受众(脚本 / CI runner)。#6531 的裁定是对os login这一条做的,没有裁os cloud login—— 所以当下的分歧是未经裁定的,不是有意为之的差异。分歧面还会长:任何将来读这两条命令之一的文档或脚本,都会把自己看到的那种形状当成「CLI 的
--json就是这样」。需要裁定的分岔(不预设)
os cloud login --json对齐 NDJSON —— 两条命令同一契约,自动化都能拿到 URL。代价:os cloud login --json的 stdout 从单文档变成事件流,是用户可见的破坏性变化(它今天的单文档形状是可用的,有消费者也说不定)。--json是单文档 / 是 NDJSON」以及为什么。零行为变化,但等于承认同一个 CLI 里--json有两种含义。os login --json(device flow) writes TWO JSON documents to stdout, so the whole stream is unparseable #6531 的裁定 —— 若认为单文档才是--json的唯一正确含义,那os login应回到路线 1/3。相关
#6531(裁定与 PR #6727)、#6217 / PR #6524(
--jsonstdout 纯净度的同一受众家族)、#6728(os login --json在非 TTY 下把裸Email:提示写进 stdout 并以 exit 13 退出 —— 另一条路径,已单独立)。Blocked-by: #6727