boost-skill-cli 1.2.165__tar.gz → 1.2.167__tar.gz

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.165
+Version: 1.2.167
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.165'
-__version_tuple__ = version_tuple = (1, 2, 165)
+__version__ = version = '1.2.167'
+__version_tuple__ = version_tuple = (1, 2, 167)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/boost_cli/core/journal.py

@@ -52,7 +52,7 @@ def log(action: str, subject: str = "", **fields) -> None:
     p = paths.pulse_path()
     try:
         p.parent.mkdir(parents=True, exist_ok=True)
-        with p.open("a") as f:
+        with p.open("a", encoding="utf-8") as f:
             f.write(json.dumps(event) + "\n")
     except OSError as e:
         if not _WARNED_UNSAVED:

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.2.165
+Version: 1.2.167
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License-Expression: Apache-2.0

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/boost_skill_cli.egg-info/SOURCES.txt

@@ -655,6 +655,7 @@ docs/roadmap/items/serve-is-a-searchable-catalogue.md
 docs/roadmap/items/serve-py-traversal-guards-untested.md
 docs/roadmap/items/shard-refresh-skips-processed-commits.md
 docs/roadmap/items/shard-runs-reembed-everything-weekly.md
+docs/roadmap/items/shard-weights-do-not-predict-the-job-timeout.md
 docs/roadmap/items/shards-pipeline-never-produced-a-shard.md
 docs/roadmap/items/shareable-catalogue-bundle.md
 docs/roadmap/items/shift-left-gate-pre-commit-pre-commit-ci.md
@@ -723,6 +724,7 @@ docs/roadmap/items/workflow-linting-actionlint.md
 docs/roadmap/items/workflow-sast-zizmor.md
 docs/roadmap/items/workspace-scope-install.md
 docs/roadmap/items/wrap-width-judged-by-stdout.md
+docs/roadmap/items/writers-whose-bytes-are-compared-do-not-pin-their-newline.md
 docs/roadmap/items/zip-strict-audit.md
 docs/roadmap/items/zizmor-ignores-drift-and-make-lint-never-ran-it.md
 docs/roadmap/items/zizmor-pin-is-a-yanked-release.md
@@ -1031,7 +1033,6 @@ tests/unit/test_measure_registry.py
 tests/unit/test_minisign.py
 tests/unit/test_mutation_hardening.py
 tests/unit/test_mutation_shards.py
-tests/unit/test_mutation_shards_names_its_encoding.py
 tests/unit/test_mutation_subfile_shards.py
 tests/unit/test_mutation_weights_drift.py
 tests/unit/test_mutmut_source_paths.py
@@ -1103,6 +1104,7 @@ tests/unit/test_sync_blocked_links.py
 tests/unit/test_sync_lost_lock.py
 tests/unit/test_sync_repairs_gutted_skill.py
 tests/unit/test_tap_pins.py
+tests/unit/test_text_io_names_its_encoding.py
 tests/unit/test_token_parity.py
 tests/unit/test_toolchain_lock.py
 tests/unit/test_trustaudit.py

boost_skill_cli-1.2.167/docs/roadmap/items/shard-weights-do-not-predict-the-job-timeout.md

@@ -0,0 +1,57 @@
+---
+id: shard-weights-do-not-predict-the-job-timeout
+board: code
+section: trust
+status: planned
+category: CI · Bug
+complexity: M
+impact: High
+wow: 4
+note: the pack is balanced to within 700ms of ideal and a shard still timed out at 75 min, cancelling a release
+order: 364
+owner:
+pr:
+title: "Mutation shard weights balance perfectly and predict nothing, so a shard can time out and cancel a release"
+---
+<b>Observed, on the merge of #1015.</b> <code>mutation-shard (4)</code> ran 75 minutes against the
+job's <code>timeout-minutes: 75</code> and was cancelled. The aggregate <code>mutation</code> job
+then failed, the whole <code>ci</code> run concluded <code>cancelled</code> rather than
+<code>failure</code>, and <code>publish.yml</code> &mdash; which gates on
+<code>workflow_run.conclusion == 'success'</code> &mdash; skipped. <b>A merge to main silently did
+not ship</b>, which is the exact failure mode the long comment above <code>ci.yml</code>'s
+<code>concurrency:</code> block was written to prevent by a different route.
+
+<b>The packer is not at fault, and that is the finding.</b>
+<code>mutation_shards.py plan --shards 6 --explain</code> reports every shard within <b>700 ms</b>
+of the ideal 6,884,259 ms &mdash; a balance of 0.01%. The same run measured 39, 27, 38, 36,
+<b>76</b> and 65 minutes. Perfect balance against numbers that do not predict wall clock.
+
+<b>The units are the tell.</b> Total weight is 41,305,555 ms over six shards, so the plan
+predicts <b>114 minutes per shard</b> while shards finish in 27&ndash;76. The weights are
+self-consistent ratios measured somewhere other than a CI runner, and ratios are all the
+packer needs &mdash; but it means <b>nothing in the repo can answer "will a shard exceed the
+cap?"</b>. <code>plan --explain</code> prints the speedup cap and the largest unit; it never
+mentions <code>timeout-minutes</code>, and <code>grep</code> finds no comparison between the two
+anywhere in <code>scripts/mutation_shards.py</code>.
+
+<b>Run-to-run variance eats the margin.</b> The same tree, built twice: shard 4 took 66 min on
+<code>5aaf8bc4</code> (the PR) and 76 min on <code>f196160d</code> (its merge commit); shard 5 went
+42 &rarr; 65. On <code>8c4a5094</code> shard 4 was 32. So the heaviest shard's observed range is
+32&ndash;76 minutes for identical work, and the cap is 75. Related and probably the same cause:
+<code>mutation-shard (4)</code> on #1012 died at 15.1 minutes with exit 143 (SIGTERM), diagnosed
+then as runner eviction.
+
+<b>Why the open weights-refresh PR does not fix it.</b> #1014 re-measures and re-packs; under its
+weights the plan is again balanced to within ~400 ms, and predicts 121 min/shard. Re-measuring a
+quantity that was never in runner time produces a better-calibrated version of the same
+unanswerable question.
+
+<b>Shape of the work.</b> Three independent pieces, in increasing order of how much they fix:
+calibrate the weights against observed job duration (the API has it per shard, per run) so the
+plan is in minutes a human can compare to the cap; have <code>plan</code> fail, or at least warn,
+when a packed shard's predicted time is within some margin of <code>timeout-minutes</code>; and
+give the heaviest shard headroom &mdash; at eight shards the ideal drops by a quarter, and the
+speedup cap is 6.0x only because <code>store.py</code> is split per function already, so more
+shards is cheap. Separately, a cancelled <code>ci</code> on main should be loud: it currently
+looks identical to a success from the release path's point of view, because
+<code>publish.yml</code> only asks whether the conclusion was <code>success</code>.

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/docs/roadmap/items/text-io-leaves-its-encoding-to-the-locale.md

@@ -2,16 +2,16 @@
 id: text-io-leaves-its-encoding-to-the-locale
 board: code
 section: compat
-status: planned
+status: shipped
 category: Portability · Windows
 complexity: M
 impact: Med
 wow: 2
-note: 73 reads and writes take the locale's encoding; 910 writes take its line ending
+note: all 73 encoded; the guard is repo-wide over 414 files; the newline half is its own card
 order: 362
-owner:
-pr:
-title: "73 reads and writes leave the text encoding to the locale, and the Windows jobs are the only thing that notices"
+owner: loop/text-io-encoding
+pr: 1015
+title: "73 reads and writes left the text encoding to the locale, and the Windows jobs were the only thing that noticed"
 ---
 <code>Path.read_text()</code>, <code>Path.write_text()</code> and <code>open()</code> in text mode use
 <code>locale.getencoding()</code> when no <code>encoding=</code> is given. On Linux and macOS that is UTF-8
@@ -52,21 +52,35 @@ have refused a valid measurement and said "not readable JSON".
 <b>preview</b> rule, so <code>ruff check --select PLW1514</code> without <code>--preview</code> checks
 nothing at all and prints "All checks passed" &mdash; indistinguishable from a clean tree, and a trap
 this card fell into once already. And with <code>--preview</code> it resolves the receiver
-syntactically: over <code>origin/main</code> it reports exactly <b>one</b> site,
-<code>scripts/mutation_shards.py:718</code>, because it sees <code>path.read_text()</code> where
-<code>path = Path(...)</code> is in view; it never saw the <code>md.read_text()</code> off a pytest
-<code>tmp_path</code> fixture that actually broke CI. #1012 fixed that one site, so on <code>main</code>
-after this merge the rule reports <b>zero</b> while the walker still reports 73 &mdash; which is the
-clearest statement of the gap there is. The sweep wants the AST walker in
-<code>tests/unit/test_mutation_shards_names_its_encoding.py</code>, whose <code>WATCHED</code> tuple is the
-list to grow &mdash; it already pins the two files #1012 owns, so the guard generalises by adding a path
-rather than by being rewritten.
+<em>syntactically</em>, which over this repo means it sees almost nothing: run against the
+pre-sweep tree it reports <b>0</b> sites to the walker's <b>73</b>. It flags
+<code>p.read_text()</code> only where <code>p = Path(...)</code> is in view, and all 73 are a
+<code>tmp_path / "x"</code> fixture, a chained call or a parameter &mdash; including the
+<code>md.read_text()</code> that actually broke CI. 0 against 73 is the clearest statement of the gap
+there is, and the reason the rule was not simply switched on. Turning it on also means turning
+<code>preview</code> on in <code>pyproject.toml</code>, which changes how every other selected rule
+behaves; one rule, for 0 of the 73, is not that trade.
 
-<b>Shape of the work.</b> Mechanical but not blind: each site needs a decision between
-<code>encoding="utf-8"</code> and <code>read_bytes()</code>/binary mode, and a handful read files boost did
-not write (a user's <code>CLAUDE.md</code>, a tapped repo's Markdown) where <code>errors="replace"</code> may
-be the honest answer rather than a crash. Land it per-directory so each PR stays reviewable, extending
-<code>WATCHED</code> as it goes.
+<b>What shipped.</b> All 73 sites name <code>encoding="utf-8"</code>, and the guard
+&mdash; renamed <code>tests/unit/test_text_io_names_its_encoding.py</code>, since it is no longer about
+the shard planner &mdash; walks every root holding Python rather than a <code>WATCHED</code> list of two:
+<code>boost_cli</code>, <code>boost_langchain</code>, <code>evals</code>, <code>scripts</code>,
+<code>tests</code> and <code>noxfile.py</code>, <b>414</b> files. Its <code>EXEMPT</code> set is empty and
+documented to stay empty: a call that should not be flagged is a bug in <code>_is_file_open</code> or
+<code>_mode</code>, where fixing it covers every file, not an entry that mutes one. The
+<code>./boost</code> launcher is the one deliberate omission &mdash; it is a bash shim that
+<code>ast.parse</code> cannot read and that opens no files.
+
+<b>The single <code>boost_cli</code> site was the interesting one.</b>
+<code>journal.log</code> appended to the pulse feed with <code>p.open("a")</code> while
+<code>journal.events</code> read it back with <code>encoding="utf-8"</code>. That asymmetry is latent
+rather than live: <code>json.dumps</code> defaults to <code>ensure_ascii=True</code>, so every byte
+written today is ASCII and cp1252 agrees with UTF-8 about all of them. What makes it worth fixing is
+the reader's <code>errors="replace"</code>, which would turn the first byte they ever disagreed about
+into U+FFFD without raising &mdash; a feed that silently loses a character rather than failing. A
+round-trip test cannot show any of this on Linux, so the test watches the argument reaching
+<code>Path.open</code> instead of the bytes on disk; dropping the keyword and misspelling the codec
+both fail it.
 
 <b>The encoding is only half of what text mode decides.</b> It also translates <code>\n</code> to the
 platform separator on write, so a file written with <code>encoding="utf-8"</code> on a Windows runner
@@ -76,8 +90,14 @@ the encoding leaves every writer whose output is compared against a string, a ha
 still platform-dependent, so this card covers <code>newline="\n"</code> on writers as well &mdash;
 readers need nothing, since universal newlines already fold CRLF on the way in.
 
-That second sweep is <b>910</b> writes (857 tests, 32 <code>boost_cli</code>, 21 <code>scripts</code>),
-and unlike the encoding it should <em>not</em> be applied everywhere: a write whose bytes nobody
-compares is fine as it is. The ones that matter are writers whose output is read back and compared
-&mdash; against a string, a hash, a golden file, or the same report printed to a log. Scoping that
-subset is the first task of this card, not a mechanical pass.
+That second sweep is <b>917</b> writes on the tree this change ships (858 <code>tests</code>, 32
+<code>boost_cli</code>, 21 <code>scripts</code>, 6 <code>evals</code>; 916 on <code>origin/main</code>,
+and the 910 this card first quoted was the same count taken before <code>evals</code> was in the walk)
+and is <b>deliberately not in this change</b>, because unlike the encoding it
+must <em>not</em> be applied everywhere: a write whose bytes nobody compares is fine as it is, so a
+blanket pass would be 917 edits of which most are churn and none is a fix. Scoping the subset that
+is read back and compared is work of its own, and it has its own card &mdash;
+<code>writers-whose-bytes-are-compared-do-not-pin-their-newline</code>. The newline walker
+(<code>unpinned_newline</code>) ships here beside the encoding one, still scoped to
+<code>scripts/mutation_shards.py</code>, which is the one file whose writers are already known to be
+byte-compared.

boost_skill_cli-1.2.167/docs/roadmap/items/writers-whose-bytes-are-compared-do-not-pin-their-newline.md

@@ -0,0 +1,49 @@
+---
+id: writers-whose-bytes-are-compared-do-not-pin-their-newline
+board: code
+section: compat
+status: planned
+category: Portability · Windows
+complexity: M
+impact: Med
+wow: 2
+note: 917 text writes take the platform line ending; only the compared ones are bugs
+order: 363
+owner:
+pr:
+title: "917 text writes leave the line ending to the platform, and only some of them are bugs"
+---
+Text mode decides two things, and naming the encoding fixes one of them. It also translates
+<code>\n</code> to the platform separator <em>on write</em>, so a file written with
+<code>encoding="utf-8"</code> on a GitHub <b>Windows</b> runner still holds CRLF. The sibling card
+<code>text-io-leaves-its-encoding-to-the-locale</code> closed the encoding half across 414 files; this
+is the other half, and it is deliberately not the same kind of sweep.
+
+<b>#1012 hit both, one after the other, and the first fix hid the second.</b> Naming the encoding
+turned the three <code>tests (windows-latest, 3.1x)</code> jobs green on the assertion that had failed
+&mdash; and the next run put them straight back to red on the line endings of the same line. Two
+platform defects in one call, and no way to see the second until the first was gone.
+
+<b>The count is 917, and a blanket pass would be wrong.</b> 858 in <code>tests</code>, 32 in
+<code>boost_cli</code>, 21 in <code>scripts</code>, 6 in <code>evals</code>. Most of those writes
+produce files whose line endings nothing ever compares, so pinning
+<code>newline="\n"</code> on all of them is 917 edits of which the overwhelming majority are churn
+and none is a fix &mdash; and churn in a diff is what makes the real change unreviewable. Readers need
+nothing at all: universal newlines already fold CRLF to LF on the way in, which is why the guard that
+ships with the encoding card walks <em>writers only</em>.
+
+<b>So the work is the scoping, not the edit.</b> The subset that matters is writers whose output is
+read back and compared &mdash; against a string, a hash, a golden file, or the same report printed to a
+log beside it. Three shapes are known to qualify and are a good place to start the inventory:
+a file written here and read back by an assertion in the same test; anything hashed or diffed
+(<code>fingerprint</code>, the generated-file <code>--check</code> gates, golden fixtures); and
+anything a <em>second</em> process parses line by line, which is how
+<code>$GITHUB_OUTPUT</code> got onto the list. <code>scripts/mutation_shards.py</code> is already
+pinned and already guarded by <code>TestTheScriptPinsItsNewlines</code> &mdash; extending that guard a
+scoped set at a time, with the reason each set is in it, is the shape this should take.
+
+<b>What would make it falsifiable.</b> A Windows job that asserts byte equality, not string
+equality: today a round trip on Linux passes whether the newline is pinned or not, which is exactly
+the class of test the encoding card's own verification pass caught twice. The AST walker
+(<code>unpinned_newline</code> in <code>tests/unit/test_text_io_names_its_encoding.py</code>) is the
+platform-independent half and already exists; what it cannot tell you is which of the 917 are bugs.

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/docs/roadmap.html

@@ -143,7 +143,7 @@
       <div class="stat"><b>27</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>75</b><span>Planned</span></div>
-      <div class="stat"><b>518</b><span>Loop finds</span></div>
+      <div class="stat"><b>520</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -7185,81 +7185,59 @@ the stripped block. Found while verifying
       </article>
 
       <article class="cap rcard" id="text-io-leaves-its-encoding-to-the-locale">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Portability · Windows</span></div>
+        <h3>73 reads and writes left the text encoding to the locale, and the Windows jobs were the only thing that noticed</h3>
+        <p class="cardbody"><a class="writeup" href="https://github.com/jonnyeclectic/boost/blob/main/docs/roadmap/items/text-io-leaves-its-encoding-to-the-locale.md">Write-up &middot; text-io-leaves-its-encoding-to-the-locale.md</a></p>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★</b></span>
+          <span class="m">all 73 encoded; the guard is repo-wide over 414 files; the newline half is its own card</span>
+        </div>
+      </article>
+
+      <article class="cap rcard" id="writers-whose-bytes-are-compared-do-not-pin-their-newline">
         <div class="head"><span class="pill planned">Planned</span><span class="cat">Portability · Windows</span></div>
-        <h3>73 reads and writes leave the text encoding to the locale, and the Windows jobs are the only thing that notices</h3>
-        <p><code>Path.read_text()</code>, <code>Path.write_text()</code> and <code>open()</code> in text mode use
-<code>locale.getencoding()</code> when no <code>encoding=</code> is given. On Linux and macOS that is UTF-8
-and nothing ever goes wrong. On a GitHub <b>Windows</b> runner it is <b>cp1252</b>, so the same file
-written by one call and read by another comes back as different text the moment it holds a
-character outside Latin-1.
-
-An AST sweep of <code>boost_cli</code>, <code>scripts</code>, <code>tests</code> and <code>evals</code> finds
-<b>73</b> such sites &mdash; 72 in the test suite, 1 in <code>boost_cli</code>
-(<code>core/journal.py:55</code>, <code>with p.open("a")</code>) and none in <code>scripts</code>. The
-test-suite concentration is not the harmless part: a test that writes UTF-8 and reads it back in
-cp1252 is exactly the shape that reddened three Windows jobs below.
-
-<b>That figure was 116 in the first draft of this card, and the 43 it lost are the point.</b> An
-inflated backlog is not a safe error &mdash; it sizes a sweep nobody can finish and plants a
-false-positive the guard will fail on. Thirty of the 43 were <code>tarfile.open(path, "w:gz")</code>,
-three <code>os.open</code> (a file descriptor, which has no encoding), two
-<code>webbrowser.open(url)</code>, one a urllib response, and seven were binary
-<code>Path.open("rb")</code> miscounted because the walker read the mode from the builtin's argument
-position rather than <code>Path.open</code>'s. The single most misleading line was the one claiming
-17 <code>boost_cli</code> sites "would mis-read a user's own file": sixteen of those seventeen were
-not text IO at all.
-
-<b>This is not theoretical, and it already cost a build.</b> #1012 added a <code>drift</code> report
-written with <code>encoding="utf-8"</code> containing an em dash, and a test that read it back with a bare
-<code>read_text()</code>. Every Linux and macOS job passed; all three
-<code>tests (windows-latest, 3.12 / 3.13 / 3.14)</code> jobs failed, on a change that had touched nothing
-platform-specific. The failure names neither the encoding nor the character &mdash; it prints two
-truncated strings that look identical.
-
-<b>The quieter half is worse than the loud one.</b> A missing encoding on a <em>reader</em> raises
-<code>UnicodeDecodeError</code>, which is a subclass of <code>ValueError</code> &mdash; so any
-<code>except (OSError, ValueError)</code> around a JSON load swallows it and reports a perfectly good
-file as unreadable. <code>mutation_shards._unusable</code> had exactly that shape: on Windows it would
-have refused a valid measurement and said "not readable JSON".
-
-<b>Why ruff's <code>PLW1514</code> is not the whole answer.</b> Two reasons, both measured. It is a
-<b>preview</b> rule, so <code>ruff check --select PLW1514</code> without <code>--preview</code> checks
-nothing at all and prints "All checks passed" &mdash; indistinguishable from a clean tree, and a trap
-this card fell into once already. And with <code>--preview</code> it resolves the receiver
-syntactically: over <code>origin/main</code> it reports exactly <b>one</b> site,
-<code>scripts/mutation_shards.py:718</code>, because it sees <code>path.read_text()</code> where
-<code>path = Path(...)</code> is in view; it never saw the <code>md.read_text()</code> off a pytest
-<code>tmp_path</code> fixture that actually broke CI. #1012 fixed that one site, so on <code>main</code>
-after this merge the rule reports <b>zero</b> while the walker still reports 73 &mdash; which is the
-clearest statement of the gap there is. The sweep wants the AST walker in
-<code>tests/unit/test_mutation_shards_names_its_encoding.py</code>, whose <code>WATCHED</code> tuple is the
-list to grow &mdash; it already pins the two files #1012 owns, so the guard generalises by adding a path
-rather than by being rewritten.
-
-<b>Shape of the work.</b> Mechanical but not blind: each site needs a decision between
-<code>encoding="utf-8"</code> and <code>read_bytes()</code>/binary mode, and a handful read files boost did
-not write (a user's <code>CLAUDE.md</code>, a tapped repo's Markdown) where <code>errors="replace"</code> may
-be the honest answer rather than a crash. Land it per-directory so each PR stays reviewable, extending
-<code>WATCHED</code> as it goes.
-
-<b>The encoding is only half of what text mode decides.</b> It also translates <code>\n</code> to the
-platform separator on write, so a file written with <code>encoding="utf-8"</code> on a Windows runner
-still holds CRLF. #1012 hit both, one after the other: naming the encoding turned the three Windows
-jobs green on that assertion and straight back to red on the line endings. A sweep that fixes only
-the encoding leaves every writer whose output is compared against a string, a hash or another file
-still platform-dependent, so this card covers <code>newline="\n"</code> on writers as well &mdash;
-readers need nothing, since universal newlines already fold CRLF on the way in.
-
-That second sweep is <b>910</b> writes (857 tests, 32 <code>boost_cli</code>, 21 <code>scripts</code>),
-and unlike the encoding it should <em>not</em> be applied everywhere: a write whose bytes nobody
-compares is fine as it is. The ones that matter are writers whose output is read back and compared
-&mdash; against a string, a hash, a golden file, or the same report printed to a log. Scoping that
-subset is the first task of this card, not a mechanical pass.</p>
-        <div class="meta">
-          <span class="m">Complexity <b>M</b></span>
-          <span class="m">Impact <b>Med</b></span>
-          <span class="m">Wow <b class="wow">★★</b></span>
-          <span class="m">73 reads and writes take the locale's encoding; 910 writes take its line ending</span>
+        <h3>917 text writes leave the line ending to the platform, and only some of them are bugs</h3>
+        <p>Text mode decides two things, and naming the encoding fixes one of them. It also translates
+<code>\n</code> to the platform separator <em>on write</em>, so a file written with
+<code>encoding="utf-8"</code> on a GitHub <b>Windows</b> runner still holds CRLF. The sibling card
+<code>text-io-leaves-its-encoding-to-the-locale</code> closed the encoding half across 414 files; this
+is the other half, and it is deliberately not the same kind of sweep.
+
+<b>#1012 hit both, one after the other, and the first fix hid the second.</b> Naming the encoding
+turned the three <code>tests (windows-latest, 3.1x)</code> jobs green on the assertion that had failed
+&mdash; and the next run put them straight back to red on the line endings of the same line. Two
+platform defects in one call, and no way to see the second until the first was gone.
+
+<b>The count is 917, and a blanket pass would be wrong.</b> 858 in <code>tests</code>, 32 in
+<code>boost_cli</code>, 21 in <code>scripts</code>, 6 in <code>evals</code>. Most of those writes
+produce files whose line endings nothing ever compares, so pinning
+<code>newline="\n"</code> on all of them is 917 edits of which the overwhelming majority are churn
+and none is a fix &mdash; and churn in a diff is what makes the real change unreviewable. Readers need
+nothing at all: universal newlines already fold CRLF to LF on the way in, which is why the guard that
+ships with the encoding card walks <em>writers only</em>.
+
+<b>So the work is the scoping, not the edit.</b> The subset that matters is writers whose output is
+read back and compared &mdash; against a string, a hash, a golden file, or the same report printed to a
+log beside it. Three shapes are known to qualify and are a good place to start the inventory:
+a file written here and read back by an assertion in the same test; anything hashed or diffed
+(<code>fingerprint</code>, the generated-file <code>--check</code> gates, golden fixtures); and
+anything a <em>second</em> process parses line by line, which is how
+<code>$GITHUB_OUTPUT</code> got onto the list. <code>scripts/mutation_shards.py</code> is already
+pinned and already guarded by <code>TestTheScriptPinsItsNewlines</code> &mdash; extending that guard a
+scoped set at a time, with the reason each set is in it, is the shape this should take.
+
+<b>What would make it falsifiable.</b> A Windows job that asserts byte equality, not string
+equality: today a round trip on Linux passes whether the newline is pinned or not, which is exactly
+the class of test the encoding card's own verification pass caught twice. The AST walker
+(<code>unpinned_newline</code> in <code>tests/unit/test_text_io_names_its_encoding.py</code>) is the
+platform-independent half and already exists; what it cannot tell you is which of the 917 are bugs.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★</b></span>
+          <span class="m">917 text writes take the platform line ending; only the compared ones are bugs</span>
         </div>
       </article>
       <!-- /ROADMAP:cards -->
@@ -7768,6 +7746,59 @@ had 4 clones in flight".</p>
           <span class="m">it skipped in all six jobs that run the suite, not the three this card first counted</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="shard-weights-do-not-predict-the-job-timeout">
+        <div class="head"><span class="pill planned">Planned</span><span class="cat">CI · Bug</span></div>
+        <h3>Mutation shard weights balance perfectly and predict nothing, so a shard can time out and cancel a release</h3>
+        <p><b>Observed, on the merge of #1015.</b> <code>mutation-shard (4)</code> ran 75 minutes against the
+job's <code>timeout-minutes: 75</code> and was cancelled. The aggregate <code>mutation</code> job
+then failed, the whole <code>ci</code> run concluded <code>cancelled</code> rather than
+<code>failure</code>, and <code>publish.yml</code> &mdash; which gates on
+<code>workflow_run.conclusion == 'success'</code> &mdash; skipped. <b>A merge to main silently did
+not ship</b>, which is the exact failure mode the long comment above <code>ci.yml</code>'s
+<code>concurrency:</code> block was written to prevent by a different route.
+
+<b>The packer is not at fault, and that is the finding.</b>
+<code>mutation_shards.py plan --shards 6 --explain</code> reports every shard within <b>700 ms</b>
+of the ideal 6,884,259 ms &mdash; a balance of 0.01%. The same run measured 39, 27, 38, 36,
+<b>76</b> and 65 minutes. Perfect balance against numbers that do not predict wall clock.
+
+<b>The units are the tell.</b> Total weight is 41,305,555 ms over six shards, so the plan
+predicts <b>114 minutes per shard</b> while shards finish in 27&ndash;76. The weights are
+self-consistent ratios measured somewhere other than a CI runner, and ratios are all the
+packer needs &mdash; but it means <b>nothing in the repo can answer "will a shard exceed the
+cap?"</b>. <code>plan --explain</code> prints the speedup cap and the largest unit; it never
+mentions <code>timeout-minutes</code>, and <code>grep</code> finds no comparison between the two
+anywhere in <code>scripts/mutation_shards.py</code>.
+
+<b>Run-to-run variance eats the margin.</b> The same tree, built twice: shard 4 took 66 min on
+<code>5aaf8bc4</code> (the PR) and 76 min on <code>f196160d</code> (its merge commit); shard 5 went
+42 &rarr; 65. On <code>8c4a5094</code> shard 4 was 32. So the heaviest shard's observed range is
+32&ndash;76 minutes for identical work, and the cap is 75. Related and probably the same cause:
+<code>mutation-shard (4)</code> on #1012 died at 15.1 minutes with exit 143 (SIGTERM), diagnosed
+then as runner eviction.
+
+<b>Why the open weights-refresh PR does not fix it.</b> #1014 re-measures and re-packs; under its
+weights the plan is again balanced to within ~400 ms, and predicts 121 min/shard. Re-measuring a
+quantity that was never in runner time produces a better-calibrated version of the same
+unanswerable question.
+
+<b>Shape of the work.</b> Three independent pieces, in increasing order of how much they fix:
+calibrate the weights against observed job duration (the API has it per shard, per run) so the
+plan is in minutes a human can compare to the cap; have <code>plan</code> fail, or at least warn,
+when a packed shard's predicted time is within some margin of <code>timeout-minutes</code>; and
+give the heaviest shard headroom &mdash; at eight shards the ideal drops by a quarter, and the
+speedup cap is 6.0x only because <code>store.py</code> is split per function already, so more
+shards is cheap. Separately, a cancelled <code>ci</code> on main should be loud: it currently
+looks identical to a success from the release path's point of view, because
+<code>publish.yml</code> only asks whether the conclusion was <code>success</code>.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>M</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">the pack is balanced to within 700ms of ideal and a shard still timed out at 75 min, cancelling a release</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/tests/functional/test_workspace_scope.py

@@ -400,7 +400,7 @@ def test_a_local_install_records_mcp_servers_in_the_repo(boost, tapped, repo):
     boost("install", "brainstorming", "--local")
     sidecar = repo / mcpdecl.SIDECAR
     assert sidecar.is_file(), "no .mcp.json written into the repo"
-    servers = json.loads(sidecar.read_text())[mcpdecl.SERVERS_KEY]
+    servers = json.loads(sidecar.read_text(encoding="utf-8"))[mcpdecl.SERVERS_KEY]
     assert "gh" in servers
     assert servers["gh"][mcpdecl.MARKER_KEY] == "brainstorming", \
         "the entry must name the skill that asked for it, so uninstall can reverse it"
@@ -423,7 +423,8 @@ def test_uninstalling_locally_removes_the_servers_it_added(boost, tapped, repo):
     _declare_mcp(tapped, "brainstorming")
     boost("install", "brainstorming", "--local")
     boost("uninstall", "brainstorming", "--local")
-    servers = json.loads((repo / mcpdecl.SIDECAR).read_text())[mcpdecl.SERVERS_KEY]
+    servers = json.loads(
+        (repo / mcpdecl.SIDECAR).read_text(encoding="utf-8"))[mcpdecl.SERVERS_KEY]
     assert "gh" not in servers, \
         "a skill removed from the repo must stop launching its server"
 
@@ -445,7 +446,8 @@ def test_uninstall_leaves_a_hand_written_server_alone(boost, tapped, repo):
     _declare_mcp(tapped, "brainstorming")
     boost("install", "brainstorming", "--local")
     boost("uninstall", "brainstorming", "--local")
-    servers = json.loads((repo / mcpdecl.SIDECAR).read_text())[mcpdecl.SERVERS_KEY]
+    servers = json.loads(
+        (repo / mcpdecl.SIDECAR).read_text(encoding="utf-8"))[mcpdecl.SERVERS_KEY]
     assert servers["mine"] == {"command": "my-own-thing"}, \
         "boost must only reverse what boost wrote"
 

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/tests/unit/test_canary_deps.py

@@ -918,8 +918,8 @@ class TestGuardDetection:
         files never touch it, and one imports it without a guard.
         """
         (tmp_path / "a_test.py").write_text(
-            "import pytest\nwidget = pytest.importorskip('widget')\n")
-        (tmp_path / "b_test.py").write_text("import widget\n")
+            "import pytest\nwidget = pytest.importorskip('widget')\n", encoding="utf-8")
+        (tmp_path / "b_test.py").write_text("import widget\n", encoding="utf-8")
         required, optional = _scan([tmp_path])
         assert "widget" in required
         assert "widget" not in optional

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/tests/unit/test_eval_baseline.py

@@ -73,7 +73,7 @@ class TestBaselineIsKeyedToItsQuerySet:
         ev.save_baseline(10, [_result()], golden=KEYWORD)
         ev.save_baseline(10, [_result(**{"recall@k": 0.69, "hit@1": 0.24})],
                          golden=NATURAL)
-        data = json.loads(baseline.read_text())
+        data = json.loads(baseline.read_text(encoding="utf-8"))
         keys = set(data["sets"])
         assert len(keys) == 2, "one set's baseline overwrote the other: %s" % keys
 
@@ -96,9 +96,11 @@ class TestBaselineIsKeyedToItsQuerySet:
         # Editing the queries changes what the numbers mean, even under the same
         # filename — so identity is the content, not the path.
         golden = tmp_path / "golden.jsonl"
-        golden.write_text('{"query": "a", "relevant": ["x"], "kind": "skill"}\n')
+        golden.write_text('{"query": "a", "relevant": ["x"], "kind": "skill"}\n',
+                encoding="utf-8")
         ev.save_baseline(10, [_result()], golden=golden)
-        golden.write_text('{"query": "b", "relevant": ["y"], "kind": "skill"}\n')
+        golden.write_text('{"query": "b", "relevant": ["y"], "kind": "skill"}\n',
+                encoding="utf-8")
         assert ev.check_regressions([_result(**{"recall@k": 0.1})],
                                     eps=0.02, golden=golden) == []
 
@@ -111,7 +113,7 @@ class TestBackCompat:
             "k": 10,
             "engines": {"BM25 full-content": {
                 "recall@k": 1.0, "hit@1": 0.78, "MRR": 0.86, "nDCG@k": 0.89}},
-        }))
+        }), encoding="utf-8")
         problems = ev.check_regressions([_result(**{"hit@1": 0.10})],
                                         eps=0.02, golden=KEYWORD)
         assert problems, "a pre-existing baseline stopped catching regressions"
@@ -121,7 +123,7 @@ class TestBackCompat:
             "k": 10,
             "engines": {"BM25 full-content": {
                 "recall@k": 1.0, "hit@1": 0.78, "MRR": 0.86, "nDCG@k": 0.89}},
-        }))
+        }), encoding="utf-8")
         assert ev.check_regressions([_result(**{"hit@1": 0.10})],
                                     eps=0.02, golden=NATURAL) == []
 

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/tests/unit/test_eval_corpus.py

@@ -663,7 +663,7 @@ class TestTheCorpusSizeBlock:
         # wrong — which is how the cross-population ratio survived: the number
         # in taps.txt looked settled because nobody recomputed it.
         m = _load()
-        text = _TAPS.read_text()
+        text = _TAPS.read_text(encoding="utf-8")
         assert m.with_size(text) == text
 
     def test_the_content_line_never_says_entries(self):

{boost_skill_cli-1.2.165 → boost_skill_cli-1.2.167}/tests/unit/test_gemini_agent_sanitize.py

@@ -1219,8 +1219,9 @@ def _bundle_source() -> str:
             if not entry.is_file():
                 continue
             for chunk in sorted(set(re.findall(
-                    r"chunk-[A-Z0-9]+\.js", entry.read_text(errors="replace")))):
-                src = (root / chunk).read_text(errors="replace")
+                    r"chunk-[A-Z0-9]+\.js", entry.read_text(errors="replace",
+                            encoding="utf-8")))):
+                src = (root / chunk).read_text(encoding="utf-8", errors="replace")
                 if BUNDLE_MARKER in src:
                     return src
     return pytest.skip("Gemini CLI bundle not installed")