cli 실행 시 업데이트 체크 및 업데이트 질의

[vkehfdl1]

Cli를 시작하면 최신 npm version을 확인하고 업데이트를 y/n으로 질의 업데이트 하도록 한다.

[vkehfdl1]

AI-understood issue summary

CLI 실행 시 현재 설치된 @openclone/openclone 버전과 npm registry의 latest 버전을 비교하고, 새 버전이 있으면 사용자가 y/n으로 업데이트 실행 여부를 선택할 수 있게 하자는 요청으로 이해했습니다.

보수적 가정: 자동화/파이프/--prompt 사용을 막으면 안 되므로, 업데이트 질의는 stdin/stdout이 TTY인 대화형 실행에서만 표시하고, 비대화형 실행에서는 절대 대기하지 않도록 구현합니다.

Why this issue is needed

• npm CLI 사용자는 Claude Code skill의 SessionStart git auto-update 경로와 별개로 설치하므로, 현재 README의 npm 설치 경로(npm install -g @openclone/openclone)에는 실행 시 업데이트 안내가 없습니다. Evidence: README.md:90-103.
• npm 배포 버전은 GitHub Release tag에서 stamp/publish되므로, CLI가 registry의 latest와 로컬 package.json version을 비교하면 사용자에게 실제 배포 상태를 알려줄 수 있습니다. Evidence: package.json:2-3, .github/workflows/publish-npm.yml:22-39, .github/workflows/publish-npm.yml:47-63, README.md:257-265.
• 현 시점 research command로 npm view @openclone/openclone version dist-tags --json을 확인했을 때 registry latest는 0.4.2, 로컬 checkout의 package.json은 0.3.0이어서, 버전 drift가 실제로 발생 가능한 흐름입니다. External: npm-view | npm Docs - https://docs.npmjs.com/cli/v11/commands/npm-view/

Why this issue may not be needed

• CLI 시작 시 네트워크 호출과 질의를 추가하면 startup latency, registry 장애, 프록시/오프라인 환경, CI/agent 자동화 hang 위험이 생깁니다.
• npm 자체도 npm update -g / npm install -g <pkg>@latest로 업데이트할 수 있고, global install은 사용자 권한/EACCES/prefix에 따라 실패할 수 있습니다. External: npm-update | npm Docs - https://docs.npmjs.com/cli/v11/commands/npm-update/ ; npm-install | npm Docs - https://docs.npmjs.com/cli/v11/commands/npm-install/
• update-notifier 같은 기존 라이브러리는 non-intrusive notification 중심이며, README에서도 자동 업데이트보다 알림이 선호되었다는 배경을 설명합니다. 이 이슈의 “y/n으로 실제 업데이트” 요구와는 UX가 다르므로 dependency 도입 전 제품 의도 확인이 필요합니다. External: GitHub - sindresorhus/update-notifier - https://github.com/sindresorhus/update-notifier

Expected Outcome

• openclone 대화형 실행 시 새 latest 버전이 있으면 다음처럼 명확히 알립니다: openclone 0.3.0 -> 0.4.2 update available. Update now? [y/N].
• 사용자가 y/yes를 입력하면 npm install -g @openclone/openclone@latest 또는 동등한 업데이트 명령을 실행하고 결과를 보여줍니다.
• 사용자가 n, 빈 입력, 기타 입력을 선택하면 기존 명령 흐름을 계속합니다.
• --prompt, piped stdin, non-TTY stdout, CI, 테스트 환경에서는 질의하지 않고 기존 동작을 유지합니다.
• registry/network/update 명령 실패는 경고만 출력하고 CLI 본래 명령을 계속하거나 정상적으로 오류를 보고해야 하며, clone chat 자체를 불필요하게 막지 않습니다.
• 사용자가 업데이트 체크를 끌 수 있는 opt-out이 있어야 합니다. 예: --no-update-check 및 OPENCLONE_NO_UPDATE_CHECK=1.

Evidence-based implementation plan

Feasibility and reusable evidence

• Existing CLI entry and dispatch are centralized in src/cli/index.ts; arg parsing is hand-written at src/cli/index.ts:27-44, usage text is at src/cli/index.ts:81-90, command dispatch is at src/cli/index.ts:360-382, and central error formatting is at src/cli/index.ts:385-395. The implementation agent can insert a startup guard without changing the Claude Code skill path.
• Existing interactive gating already distinguishes TTY/non-TTY and explicit prompt/stdin: src/cli/index.ts:115-131 and src/lib/conversation.ts:84-87. Tests cover this contract in test/conversation.test.mjs:51-58. Reuse this shape so update prompts never block non-interactive automation.
• Existing readline prompt mechanics already use node:readline/promises: import at src/lib/conversation.ts:1-2, fake readline test helper at test/conversation.test.mjs:40-48, and close/cleanup patterns in conversation tests. Node official docs confirm readlinePromises.createInterface() and rl.question() are the supported promise-based prompt APIs. External: Readline | Node.js Documentation - https://nodejs.org/api/readline.html
• Existing testable network style exists in src/lib/clone-tools.ts via injected fetchImpl patterns around src/lib/clone-tools.ts:101, src/lib/clone-tools.ts:159-174, and src/lib/clone-tools.ts:193-209. Reuse this dependency-injection style for registry lookup tests rather than making tests hit npm.
• Existing child process patterns exist if the implementation shells out to npm: src/lib/claude-code-auth.ts:1-7 uses execFile + promisify; Node docs note execFile() spawns a command directly without a shell by default, which is safer than shell string interpolation. External: Child process | Node.js Documentation - https://nodejs.org/api/child_process.html
• External options found:
  • npm view <pkg> dist-tags.latest --json is officially supported for registry field access; npm docs state npm view shows registry package data and default version is latest. External: npm-view | npm Docs - https://docs.npmjs.com/cli/v11/commands/npm-view/
  • latest-version can fetch latest npm package versions directly from the registry. External: GitHub - sindresorhus/latest-version - https://github.com/sindresorhus/latest-version
  • update-notifier provides cached, TTY-only CLI update notifications and opt-out env/flag conventions, but it does not perform y/n installation by itself. External: GitHub - sindresorhus/update-notifier - https://github.com/sindresorhus/update-notifier
  • semver provides robust version comparison functions such as gt/compare; prefer it over string comparison if adding a dependency is acceptable. External: GitHub - npm/node-semver - https://github.com/npm/node-semver

Step-by-step instructions for the implementation agent

1. Add a small, isolated TypeScript module such as src/lib/update-checker.ts that exports pure/testable helpers:
   • local package name/version source, using @openclone/openclone and the bundled version from package.json or a build-time-safe equivalent (package.json:2-3);
   • fetchLatestVersion({ fetchImpl, registryUrl, packageName }) using either registry HTTP or npm view semantics;
   • isNewerVersion(current, latest) using semver.gt or a minimal semver-safe comparator;
   • shouldPromptForUpdate({ stdinIsTTY, stdoutIsTTY, flags, env }) mirroring the existing non-interactive gate in src/lib/conversation.ts:84-87.
2. Add a prompt/update runner that:
   • prints a concise update message only when latest > current;
   • uses readlinePromises.createInterface() / rl.question() per Node docs and existing prompt style;
   • treats empty input as No;
   • never asks when --no-update-check, OPENCLONE_NO_UPDATE_CHECK=1, non-TTY, --prompt, or piped stdin is present.
3. For the actual update command, prefer execFile("npm", ["install", "-g", "@openclone/openclone@latest"], ...) instead of shell strings, following the safer direct-spawn pattern from Node docs and the repo’s execFile usage in src/lib/claude-code-auth.ts:1-7. If using npm update -g, account for npm docs warning that global update may not always move to latest; npm install -g @openclone/openclone@latest is likely clearer. External: npm-update | npm Docs - https://docs.npmjs.com/cli/v11/commands/npm-update/ ; npm-install | npm Docs - https://docs.npmjs.com/cli/v11/commands/npm-install/
4. Wire the startup check in src/cli/index.ts before command dispatch or at the top of commands that represent “CLI start”. Conservative recommendation: run before chat, list, status, and history only when interactive TTY and not disabled, but skip help/--help to avoid delaying help output. Update usage() at src/cli/index.ts:81-90 with the opt-out flag/env.
5. Add tests before/with implementation:
   • unit tests for isNewerVersion, opt-out env/flag, TTY gate, network failure fallback, and user answers (y, yes, n, empty);
   • a CLI-level or module-level test proving --prompt/piped stdin/non-TTY do not call rl.question(), extending the existing interactive gating coverage in test/conversation.test.mjs:51-58;
   • a test with fake fetchImpl modeled after src/lib/clone-tools.ts patterns, so CI does not depend on npm registry.
6. Documentation:
   • update README/README_en/README_zh CLI sections if user-visible flags/env are added;
   • mention that update checks are best-effort and TTY-only.
7. Validation target for the implementation agent:
   • npm run build
   • npm test
   • if README files change, node .github/scripts/validate-readme-i18n.ts and npx markdownlint-cli2 "**/*.md" as relevant.

Risks and assumptions

• Assumption: “cli 시작” means installed standalone Node CLI startup, not Claude Code slash-command skill startup.
• Assumption: y/n prompt is acceptable only in TTY; non-interactive automation must never wait for human input.
• Risk: self-updating a globally installed package may fail due to npm prefix permissions, Corepack/npm availability, Windows command resolution, or user-installed package managers. The implementation should show the attempted command and a manual fallback if update execution fails.
• Risk: adding update-notifier, latest-version, or semver increases dependencies. semver is the lowest-risk dependency for comparison; direct registry fetch can avoid adding latest-version; update-notifier is less aligned if product requires y/n installation.

Open questions for the human

None required before /approve under the conservative assumptions above. If you want different behavior, please comment before approving:

1. Should the update check run for every command (list, status, history, chat) or only chat?
2. Should y run npm install -g @openclone/openclone@latest, or only print the command for the user to run manually?
3. Should there be a throttle/cache interval (for example daily) to avoid checking npm on every TTY startup?

Approval reminder

Implementation starts only after a human follow-up comment containing /approve. The implementation agent will use this comment as the self-contained handoff and should not assume access to this planning session’s hidden reasoning.

Agent Signature

[vkehfdl1]

/approve