[oratis]

第 4 / 8 条，实现 UX-9 与 T-3、T-11 的 CLI 部分。基于 #371。

做了什么

日志噪音与路径（UX-9）。 [proxy] outbound HTTP routed through … 之前每条命令都打印，现在只在 --verbose 或 LISA_DEBUG=1 下出现（serve 启动时仍保留一行）。所有面向用户的路径统一用 ~ 缩写——缺密钥的报错之前会打出 200 多字符的绝对路径。

REPL。 持久化历史（~/.lisa/history，0600，上限 1000 行，跳过空行与连续重复）；ANSI 颜色助手，遵守 NO_COLOR、--no-color 和非 TTY；工具调用压缩成单行——运行中 ⚙ bash npm test，结束时 ✓ bash (1.2s) 或 ✗ bash (0.3s): <首行错误>，完整结果只在 --verbose 下展开；发送提示词到首个响应之间显示 spinner（仅 TTY，走 stderr）；thinking 事件显示为暗色标记但从不打印思考内容。stdout 仍然只承载 Lisa 的正文，管道用法不受影响。

lisa doctor --probe [url]。 探测运行中后端的 /health，打印版本、运行时长、事件循环延迟、堆内存、租户数；p99 超过 1000ms 标警告；不可达时退出码非零。同时兼容只返回 {ok:true} 的旧服务端。

lisa upgrade。 识别安装方式（Homebrew / npm 全局 / 源码检出），执行对应升级，打印升级前后版本；若 LaunchAgent 已加载则顺带 launchctl kickstart 让守护进程用上新代码——这正是此前需要手工执行 6 条命令的场景。--check 只比对版本，--dry-run 只打印将要执行的命令。

验证

新增逻辑均有测试（渲染器用假的非 TTY writer，探测用端口 0 的本地服务，升级只测纯检测与命令拼装，不联网不真装）。无新增运行时依赖。

🤖 Generated with Claude Code

[oratis]

评审 — 承诺逐条实跑；补上失败升级的出路

已 rebase 到 main，base 改为 main，无冲突。

承诺实测（不是读代码，是真跑）

承诺	实测
proxy 日志默认静默	HTTPS_PROXY=… lisa --help → 0 条；加 LISA_DEBUG=1 → 1 条 ✓
路径用 ~ 缩写	缺密钥报错输出 ~/.lisa/config.env（HOME 外的路径仍显示绝对路径，正确） ✓
历史 0600 / 去重 / 限长	实写后 mode: 600，["hello","hello","","world"] → "hello\nworld\n"，无残留 .tmp ✓
doctor --probe 不可达时退出非零	exit=1，并提示 try lisa serve --web ✓
upgrade --dry-run 不动源码检出	正确识别为 source checkout 并拒绝触碰工作树 ✓
NO_COLOR / --no-color / 非 TTY	三种情况转义序列数均为 0 ✓

结构性检查

命令执行面干净。 upgrade.ts 把命令构造成 {cmd, args} 常量数组，执行走 launchd.ts 的 runCmd，即 spawn(cmd, args) 不带 shell: true —— 没有注入面。源码检出被刻意排除在自动升级之外（"git pull 到别人的工作树上不是升级，是合并"），这个判断是对的。

probe.ts 不带任何令牌，只发 accept: application/json，所以不会把凭据泄给用户随手输入的主机。（附带含义：/health 必须是免鉴权的 —— 我会在评审 #373 时重点检查它新增的租户数/堆内存字段在云端的暴露面。）

"thinking 内容从不打印"是结构性保证，不是约定。 onThinking() 不接受任何参数，而分发处 case "thinking_delta": onThinking(); 直接把事件文本丢弃 —— 即使有人想打印也无从取值。这比一句注释强得多。

spinner 定时器 h.unref()，不会在工作结束后吊住进程。

已修：升级失败后没有出路

失败路径原本是打印 npm 报错的第一行然后停止：

✗ npm exited 1: npm ERR! code EACCES
`npm install -g @oratis/lisa@latest` failed — Lisa is still on 0.24.0

问题有两层：

1. EACCES 是这条命令最常见的失败——sudo npm install -g 会成为民间偏方就是这么来的。
2. native: Swift 警告清零并转为错误；Mac 后端安装向导；iOS 可访问性与推送通道 #371 已经给 Mac 向导写好了免 sudo 的 prefix 修复（BackendSetup.permissionsFixScript）。同一个用户，同一条 npm install -g，从 App 得到修复、从 CLI 得到死胡同。

新增 classifyUpgradeFailure()，needle 与 Mac 侧 classifyInstallFailure() 一一对应，两个表面不会在同一条命令上给出互相矛盾的说法。permissions 分支逐字输出向导那几条命令：

npm can't write to its global folder — it's owned by root.
The standard fix moves global packages into your home folder (no sudo), then retries:
  mkdir -p "$HOME/.npm-global"
  npm config set prefix "$HOME/.npm-global"
  grep -qs 'npm-global/bin' "$HOME/.zprofile" || echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> "$HOME/.zprofile"
  export PATH="$HOME/.npm-global/bin:$PATH"
  npm install -g @oratis/lisa@latest

一个实现细节值得说：分类读整条消息而不是第一行。runCmd 以 npm exited 1: <stderr> 形式 reject，而 EACCES / EBADENGINE 这类 needle 几乎从不在第一行——这正是原来"只打印第一行"没有信息量的原因。

测试覆盖四种分类、真实多行报错形状、任何分支都不会给出裸 sudo npm install（那恰恰是 root 属主目录的成因），以及 MIN_NODE_MAJOR 与 package.json 的 engines.node 保持同步。

验证

npm run typecheck 通过；npm test 1817 个，1816 通过，0 失败，1 跳过（PTY，Node 26 已知）；npm run build 通过。本 PR 自带约 99 个新测试，质量高——render.test.ts 用假的非 TTY writer 驱动、probe.test.ts 用端口 0，都没有留下真实副作用。

🤖 Generated with Claude Code