fix(diffStix): write the changelog markdown as UTF-8

[ppcvote]

What breaks

get_new_changelog_md opens the markdown file without an encoding, so CPython falls back to the locale codec. ATT&CK changelog text is not ASCII, so the write raises on any machine whose locale encoding is not UTF-8:

UnicodeEncodeError: 'cp950' codec can't encode character '\u041e' in position 238
  changelog_helper.py:2433 in get_new_changelog_md

Reproduced on Windows with a cp950 console. cp1252, the default on en-US Windows, fails the same way on Cyrillic. Linux and macOS default to UTF-8, which is why CI has never seen it.

The blast radius is larger than the one file. That write sits at the top of the output block in get_new_changelog_md, so the exception also skips the HTML writer, the detailed HTML writer, the layer writers and the JSON writer. A run ends with an empty markdown file and none of the other artifacts.

This looks like an oversight rather than a decision: the sibling writers in the same module already pass the encoding explicitly, at line 1849 and line 1955.

The change

One argument at changelog_helper.py:2432:

-        with open(markdown_file, "w") as file:
+        with open(markdown_file, "w", encoding="utf-8") as file:

The other bare opens in this module are deliberately left alone. Lines 1861, 1866, 1871 and 2465 also open without an encoding, but they write through json.dump, whose ensure_ascii default keeps the payload ASCII, so they do not raise today. Happy to include them if you would rather the module be clean under -X warn_default_encoding, but they are a different question from this bug.

Three read_text() calls in the tests get the matching encoding. Before this change the round trip was symmetric by accident, locale-encoded at both ends. Once the writer is UTF-8, a reader that does not say so decodes with the locale codec, and file_content == markdown_result compares a mis-decoded string against the original. On my machine that turned two passing tests red, which is how I found them; on Linux CI they would have stayed green and the assertion would have quietly stopped meaning anything.

About the test

It drives the writer in a subprocess under -X warn_default_encoding -W error::EncodingWarning rather than asserting on a round trip.

A round trip is the obvious test and it is useless here: it passes on an unfixed tree wherever the locale encoding is already UTF-8, so it would have gone green on your CI both before and after the fix. I checked that before writing this one. Under PEP 597 any open() that relies on the locale codec becomes an error, so the test fails on every platform if the encoding argument goes missing again, and the traceback names the exact line.

The driver passes layers=[] and json_file=None so only the markdown writer is exercised, keeping the assertion pointed at one thing.

Verification

• New test: fails on unmodified main, passes with the fix. Confirmed in both directions by stashing the change and re-running.
• tests/changelog: 7 failures before this change and the same 7 after, none of them new. They are all in cli/ and are pre-existing Windows environment assumptions, for example a pytest.raises(PermissionError) that Windows does not raise.
• ruff check and ruff format --check clean on all four touched files.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud