release v0.9.5 — deferred items tracker (post-review)

Bắt đầu với packages/opencode/src/altimate/telemetry/index.ts::doInit và FIXME trong packages/opencode/src/cli/welcome.ts, sau đó kiểm tra CI job windows-ripgrep-e2e và lần chạy thất bại. Xác nhận hành vi opt-out khi cold-start và xác định cách các flaky failure sẽ được cách ly và ghi nhận; hoàn tất có nghĩa là cả hai đường đi đều được bao phủ bằng việc xác minh và các lỗi trong tương lai có thể được quan sát mà không chỉ dựa vào việc chạy lại.

Tracker for items surfaced during the v0.9.5 pre-release multi-persona review that were explicitly deferred — either because they need significant design work (>30 min), require investigation beyond the release window, or are pre-existing issues we don't want to hide inside a code comment.

None of these blocked the v0.9.5 release (PR #1086); the actionable P1s were fixed there. This issue exists so the deferred items don't get lost.

D — CI flake tracker: windows-ripgrep-e2e + ERR_STREAM_PREMATURE_CLOSE

Flagged by: CTO (P2), Chaos Gremlin (P2)

Symptom: A TypeScript CI job failed on merge commit 092567a8d2 with ERR_STREAM_PREMATURE_CLOSE in an unrelated test file. Chaos verified it was a flake, not a regression, by observing that the next main-branch CI run was fully green. Separately, the new windows-ripgrep-e2e job (added in #1074 to prevent regressing the Windows grep fix from #1072) is worth quarantining upfront since PowerShell/CI-runner interactions historically flake.

Ask: Add a quarantine + observability workflow so future flakes on either surface get logged and triaged rather than waved through with a re-run. In the meantime, whenever a re-run is used, link to this issue in the run notes.

Not doing now because: Not a code bug — process + observability work that needs someone to think about the shape (SigNoz dashboard? GH action? Slack ping?), which is out of scope for a release fix.

F — Telemetry: config-only opt-out can still mint a machine-id on cold-start

Flagged by: PM (P2)

Symptom: Telemetry.doInit() may run before Instance.provide() has made Config.get() resolvable — the catch branch in packages/opencode/src/altimate/telemetry/index.ts::doInit proceeds with telemetry enabled when Config throws. A user who opted out via the telemetry.disabled config key with no env var set can therefore still get a machine-id minted on first launch. Also flagged by FIXME(telemetry-init-config-opt-out) anchor in packages/opencode/src/cli/welcome.ts as of commit 388f41bc.

The env-var opt-out (ALTIMATE_TELEMETRY_DISABLED / OPENCODE_DISABLE_TELEMETRY) is unaffected — that check doesn't need Instance context.

Ask: Either move Telemetry.doInit() behind Instance.provide() for the cold-start path, or add a separate config probe that reads the file directly (no Instance dependency) before minting.

Not doing now because: Pre-existing (predates v0.9.5), not a regression. The fix touches init ordering across the CLI, which needs careful design rather than a release-hotfix.

Also from the review — not being tracked here

• Org-level YOLO fleet-lockout (Chaos P1): explicitly out of scope, needs cross-repo policy design.
• Welcome-panel narrow-terminal manual QA (CTO P1): process/QA work, no code target.
• @zip.js/zip.js supply-chain watch (CTO P2): already exact-pinned at 2.7.62, no code action needed.