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

Inizia da packages/opencode/src/altimate/telemetry/index.ts::doInit e dal FIXME in packages/opencode/src/cli/welcome.ts, quindi esamina il job CI windows-ripgrep-e2e e l'esecuzione non riuscita. Conferma il comportamento di opt-out al cold start e definisci come i flakes verranno messi in quarantena e registrati; il lavoro è concluso quando entrambi i percorsi sono coperti dalla verifica e i futuri errori sono osservabili senza affidarsi soltanto a nuove esecuzioni.

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.