fix(preflight): read desktop changelog as UTF-8

[tianmind-studio]

Summary

• reads and writes desktop changelog JSON with an explicit UTF-8 encoding
• adds a behavioral encoding contract for hosts whose default locale is not UTF-8
• registers the contract in the shared local/CI check manifest

Fixes #9717.

Root cause

desktop-changelog.py relied on the implicit encoding of Path.read_text() and Path.write_text(). Native Windows Python uses the process ANSI code page when no encoding is supplied, so valid UTF-8 changelog content could raise UnicodeDecodeError under a GBK locale before validation started. The write path had the same host-dependent contract and could reject changelog text not representable in the active code page.

Durable guard

The changelog boundary now always uses UTF-8 for both reads and writes. The regression tests provide path doubles that reject any omitted or non-UTF-8 encoding, and the shared check manifest runs those tests whenever the implementation or contract changes.

Real-path exercise

On native Windows Python, I cleared PYTHONUTF8 and ran python .github/scripts/desktop-changelog.py validate. The old code failed with a GBK UnicodeDecodeError; the fixed command completed successfully against the repository's real changelog data.

Product invariants affected

None. This changes repository tooling only and does not affect product behavior.

Validation

• old-code regression: test_desktop_changelog.py failed both encoding tests before the production change
• python .github/scripts/test_desktop_changelog.py -> 2 passed
• python .github/scripts/desktop-changelog.py validate with parent PYTHONUTF8 unset -> passed
• python .github/scripts/test_run_checks.py -> 9 passed
• python -m py_compile .github/scripts/desktop-changelog.py .github/scripts/test_desktop_changelog.py -> passed
• make preflight with parent PYTHONUTF8 unset -> all 9 selected checks passed
• git diff --check origin/main...HEAD -> passed

[tianmind-studio]

Fresh downstream proof from reviewing #9720 on native Windows: with PYTHONUTF8 unset, Python reported cp936 / utf8_mode=0, and current main failed desktop-changelog.py validate with UnicodeDecodeError while reading #9720's valid changelog fragment (it contains an em dash). Cherry-picking this PR onto #9720 made the same validation pass; the two encoding contract tests also passed. This is now affecting a real concurrent contributor workflow, not only the synthetic regression fixture.

[Git-on-my-level]

Thanks for tightening this up. I reviewed the diff and also exercised the PR head locally at 69bb6fab325b76db01cd48cfaaf6d9782fc9e376:

• python3 .github/scripts/test_desktop_changelog.py passed (2 tests)
• python3 -m py_compile .github/scripts/desktop-changelog.py .github/scripts/test_desktop_changelog.py passed
• python3 .github/scripts/desktop-changelog.py validate passed

The change is narrow and looks directionally correct: explicitly pinning the desktop changelog read/write boundary to UTF-8 fixes the host-locale failure mode without changing product behavior, and the new contract test covers both the read and write paths. Registering it in the manifest is also appropriate for preventing regression.

I’m leaving this as a positive maintainer signal rather than a formal approval because it touches repo check/preflight manifest/tooling paths, which this automation treats as workflow-sensitive and leaves for a human maintainer to approve/merge.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[undivisible]

Closing as superseded by merged PR #9885, which fixed #9717 with the same explicit UTF-8 boundary and regression coverage.

[github-actions]

Hey @tianmind-studio 👋

Thank you so much for taking the time to contribute to Omi! We truly appreciate you putting in the effort to submit this pull request.

After careful review, we've decided not to merge this particular PR. Please don't take this personally — we genuinely try to merge as many contributions as possible, but sometimes we have to make tough calls based on:

• Project standards — Ensuring consistency across the codebase
• User needs — Making sure changes align with what our users need
• Code best practices — Maintaining code quality and maintainability
• Project direction — Keeping aligned with our product principles and locked invariants

Before your next PR, please skim:

• PRODUCT.md — product north star
• Product invariants — locked rules (shared chat, memory tiers, agent control plane, integrations, brand)

If this was declined for direction or taste, maintainers should cite an invariant ID or open a proposed one — ask if that citation is missing.

Your contribution is still valuable to us, and we'd love to see you contribute again in the future! If you'd like feedback on how to improve this PR or want to discuss alternative approaches, please don't hesitate to reach out.

Thank you for being part of the Omi community!