boost-skill-cli 1.0.303__tar.gz → 1.0.305__tar.gz

{boost_skill_cli-1.0.303/boost_skill_cli.egg-info → boost_skill_cli-1.0.305}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.303
+Version: 1.0.305
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.305}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.303'
-__version_tuple__ = version_tuple = (1, 0, 303)
+__version__ = version = '1.0.305'
+__version_tuple__ = version_tuple = (1, 0, 305)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.305/boost_skill_cli.egg-info}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.303
+Version: 1.0.305
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.305}/boost_skill_cli.egg-info/SOURCES.txt

@@ -546,6 +546,7 @@ tests/unit/test_typosquat.py
 tests/unit/test_updatediff.py
 tests/unit/test_util.py
 tests/unit/test_version.py
+tests/unit/test_workflow_concurrency.py
 tests/unit/test_workflow_timeouts.py
 tests/unit/test_workflows.py
 tests/visual/a11y_check.mjs

boost_skill_cli-1.0.305/docs/roadmap/items/ci-time-is-now-runner-queueing.md

@@ -0,0 +1,71 @@
+---
+id: ci-time-is-now-runner-queueing
+board: code
+section: pipeline
+status: shipped
+category: CI speed
+complexity: M
+impact: High
+wow: 4
+note: 104 job-min queued vs 236 executing — 31% of CI is waiting for a runner
+order: 62
+owner: loop/ci-concurrency
+pr: 350
+title: A third of CI job time is spent waiting for a runner, not running
+---
+With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
+<b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
+job-minutes queued</b> against <b>236 job-minutes executing</b> &mdash; <b>31%</b> of all job
+time spent waiting for a runner.
+
+<b>The obvious metric lies.</b> A run's <code>run_started_at</code> minus
+<code>created_at</code> is <b>0.0 for every run</b>, which reads as "no queueing anywhere".
+Queueing happens per <em>job</em>, not per run, so it is only visible as
+<code>job.started_at - job.created_at</code>. Anything measuring this at run level will
+conclude, wrongly, that there is nothing to fix.
+
+The per-run spread shows what drives it &mdash; median job queue by run:
+<code>c36c53a7</code> 0.1&nbsp;min, <code>c15ed9da</code> 0.1, <code>903b704f</code> 0.2,
+<code>638bffeb</code> 0.7, <code>ad71ba99</code> <b>2.5</b>, <code>9e190537</code> <b>2.9</b>.
+That is a 29&times; swing driven not by the change under test but by how many sibling
+<code>loop/*</code> branches and Dependabot PRs happen to be live at the same moment. It is why
+one merge took <b>41 minutes</b> wall clock with a max shard of only 11.4.
+
+Sharding the mutation gate made this worse on purpose: it traded one runner slot for six. That
+is the right trade for latency in isolation, and the wrong one to keep making blindly while a
+dozen branches are in flight, because every concurrent PR now multiplies its footprint. Options,
+roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
+superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
+count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
+fix.
+
+<b>Shipped: the least intrusive one, and it turned out to be a plain omission rather than a
+trade-off.</b> Seven workflows here already declare a <code>concurrency</code> group.
+<code>ci.yml</code> &mdash; the largest by a wide margin, ~36 checks including six mutation
+shards &mdash; declared none, so every push to a pull request left the whole previous run
+executing against a commit nobody was waiting on. This session alone pushed four times to one PR,
+which is 24 shard jobs of which 18 were already superseded.
+
+Two things keep the release path out of it, and the second is easy to miss. The <b>condition</b>:
+<code>cancel-in-progress: true</code> would also cancel a push to main, which
+<code>publish.yml</code> gates the release on via <code>workflow_run</code> &mdash; a merge that
+silently never ships &mdash; and a <code>merge_group</code> run, where a cancelled run never
+reports its required contexts and the queue then waits forever on a status that is not coming.
+Both evaluate false.
+
+The <b>key</b>: non-PR events group on <code>github.sha</code>, not <code>github.ref</code>.
+<code>cancel-in-progress: false</code> does not mean "never cancel" &mdash; it means a newer run
+<i>waits</i>, and GitHub cancels the older <em>pending</em> run when a third arrives. Keying main
+on its ref would put every main push in one group, so three quick merges would leave a middle
+commit whose <code>ci</code> never completes, and since <code>publish.yml</code> fires on
+<code>workflow_run</code> of <code>ci</code>, that commit would never release. A sha is unique per
+commit, so main and the merge queue never share a group at all.
+
+Both properties are pinned by tests rather than by the comment, and a separate assertion sweeps
+every workflow that triggers on <code>merge_group</code> and fails if any cancels unconditionally
+&mdash; so the deadlock cannot arrive later through a different file.
+
+What this does <em>not</em> do is reduce the footprint of a single run, which is the other half of
+the measurement. <code>max-parallel</code> on the shard matrix and an adaptive shard count are
+still open, and both trade latency for footprint rather than removing waste &mdash; worth
+re-measuring queue time after this lands before spending that trade.

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.305}/docs/roadmap/items/dependabot-root-pip-entry-duplicates-requirements.md

@@ -2,15 +2,15 @@
 id: dependabot-root-pip-entry-duplicates-requirements
 board: code
 section: internals
-status: planned
+status: shipped
 category: Build · Gap
 complexity: S
 impact: Low
 wow: 1
 note: fallout from #289 — every toolchain bump now arrives twice
 order: 35
-owner:
-pr:
+owner: loop/dependabot-root-narrow
+pr: 349
 title: Dependabot raises every toolchain bump <em>twice</em>
 ---
 PR #289 added a third Dependabot entry, <code>package-ecosystem: pip</code> with
@@ -43,3 +43,24 @@ Dependabot's file discovery is what got this wrong in the first place. <b>First<
 extras bumps are genuinely wanted, that needs <code>versioning-strategy: increase</code> so open
 lower bounds are raised at all; otherwise accept that this entry is security-only and say so in the
 comment, which is the honest smaller change.
+
+<b>Shipped &mdash; the second one, and <code>#342</code> changed why.</b> That change gave
+<code>/requirements</code> <code>open-pull-requests-limit: 0</code>, which silences the duplicate on
+one side but leaves the <code>/</code> entry as the <em>only</em> remaining path to a
+lock-regenerating pull request &mdash; precisely the thing that cannot be done correctly on a single
+platform. The duplicate stopped being the problem and the survivor became one.
+
+So the version-update side of the <code>/</code> entry is off too, and the reasoning is now written
+where the next person will look. It produces nothing wanted: every constraint under
+<code>[project.optional-dependencies]</code> is an open lower bound or sits in the entry's own
+ignore list, so its set of possible <code>pyproject.toml</code> version updates is <b>empty</b>
+&mdash; none of the eight PRs in that first run touched it. And it produces one thing actively
+harmful: four of those eight were byte-identical lock regenerations. <b>Security</b> updates ignore
+the limit and keep firing, which is the coverage the extras genuinely gained, and
+<code>lock_toolchain.py --audit</code> now catches a security PR that arrives having dropped a
+marker-gated pin.
+
+Both pip entries are pinned at <code>limit: 0</code> by
+<code>tests/unit/test_dependabot_config.py</code>, alongside an assertion that neither entry is
+<em>deleted</em> &mdash; removing them would give up the security coverage that is the whole
+remaining point. Related: [[dependabot-regeneration-drops-platform-pins]].

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.305}/docs/roadmap.html

@@ -1162,7 +1162,7 @@ every enabled agent. So narrowing is honoured and the newly-enabled-agent path i
       </article>
 
       <article class="cap rcard" id="dependabot-root-pip-entry-duplicates-requirements">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Build · Gap</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Build · Gap</span></div>
         <h3>Dependabot raises every toolchain bump <em>twice</em></h3>
         <p>PR #289 added a third Dependabot entry, <code>package-ecosystem: pip</code> with
 <code>directory: /</code>, to give <code>pyproject.toml</code>'s optional extras the proactive bump
@@ -1193,7 +1193,28 @@ Dependabot's file discovery is what got this wrong in the first place. <b>First<
 <code>/requirements</code> as the single owner of the hash-pinned lock. <b>Second</b>, if proactive
 extras bumps are genuinely wanted, that needs <code>versioning-strategy: increase</code> so open
 lower bounds are raised at all; otherwise accept that this entry is security-only and say so in the
-comment, which is the honest smaller change.</p>
+comment, which is the honest smaller change.
+
+<b>Shipped &mdash; the second one, and <code>#342</code> changed why.</b> That change gave
+<code>/requirements</code> <code>open-pull-requests-limit: 0</code>, which silences the duplicate on
+one side but leaves the <code>/</code> entry as the <em>only</em> remaining path to a
+lock-regenerating pull request &mdash; precisely the thing that cannot be done correctly on a single
+platform. The duplicate stopped being the problem and the survivor became one.
+
+So the version-update side of the <code>/</code> entry is off too, and the reasoning is now written
+where the next person will look. It produces nothing wanted: every constraint under
+<code>[project.optional-dependencies]</code> is an open lower bound or sits in the entry's own
+ignore list, so its set of possible <code>pyproject.toml</code> version updates is <b>empty</b>
+&mdash; none of the eight PRs in that first run touched it. And it produces one thing actively
+harmful: four of those eight were byte-identical lock regenerations. <b>Security</b> updates ignore
+the limit and keep firing, which is the coverage the extras genuinely gained, and
+<code>lock_toolchain.py --audit</code> now catches a security PR that arrives having dropped a
+marker-gated pin.
+
+Both pip entries are pinned at <code>limit: 0</code> by
+<code>tests/unit/test_dependabot_config.py</code>, alongside an assertion that neither entry is
+<em>deleted</em> &mdash; removing them would give up the security coverage that is the whole
+remaining point. Related: [[dependabot-regeneration-drops-platform-pins]].</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -2602,7 +2623,7 @@ missing file is now imputed at the measured mean rate, which keeps every weight
       </article>
 
       <article class="cap rcard" id="ci-time-is-now-runner-queueing">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">CI speed</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI speed</span></div>
         <h3>A third of CI job time is spent waiting for a runner, not running</h3>
         <p>With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
 <b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
@@ -2628,7 +2649,38 @@ dozen branches are in flight, because every concurrent PR now multiplies its foo
 roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
 superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
 count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
-fix.</p>
+fix.
+
+<b>Shipped: the least intrusive one, and it turned out to be a plain omission rather than a
+trade-off.</b> Seven workflows here already declare a <code>concurrency</code> group.
+<code>ci.yml</code> &mdash; the largest by a wide margin, ~36 checks including six mutation
+shards &mdash; declared none, so every push to a pull request left the whole previous run
+executing against a commit nobody was waiting on. This session alone pushed four times to one PR,
+which is 24 shard jobs of which 18 were already superseded.
+
+Two things keep the release path out of it, and the second is easy to miss. The <b>condition</b>:
+<code>cancel-in-progress: true</code> would also cancel a push to main, which
+<code>publish.yml</code> gates the release on via <code>workflow_run</code> &mdash; a merge that
+silently never ships &mdash; and a <code>merge_group</code> run, where a cancelled run never
+reports its required contexts and the queue then waits forever on a status that is not coming.
+Both evaluate false.
+
+The <b>key</b>: non-PR events group on <code>github.sha</code>, not <code>github.ref</code>.
+<code>cancel-in-progress: false</code> does not mean "never cancel" &mdash; it means a newer run
+<i>waits</i>, and GitHub cancels the older <em>pending</em> run when a third arrives. Keying main
+on its ref would put every main push in one group, so three quick merges would leave a middle
+commit whose <code>ci</code> never completes, and since <code>publish.yml</code> fires on
+<code>workflow_run</code> of <code>ci</code>, that commit would never release. A sha is unique per
+commit, so main and the merge queue never share a group at all.
+
+Both properties are pinned by tests rather than by the comment, and a separate assertion sweeps
+every workflow that triggers on <code>merge_group</code> and fails if any cancels unconditionally
+&mdash; so the deadlock cannot arrive later through a different file.
+
+What this does <em>not</em> do is reduce the footprint of a single run, which is the other half of
+the measurement. <code>max-parallel</code> on the shard matrix and an adaptive shard count are
+still open, and both trade latency for footprint rather than removing waste &mdash; worth
+re-measuring queue time after this lands before spending that trade.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m hi">Impact <b>High</b></span>

{boost_skill_cli-1.0.303 → boost_skill_cli-1.0.305}/tests/unit/test_dependabot_config.py

@@ -104,3 +104,61 @@ def test_the_root_ignore_list_matches_the_ceilings_pyproject_sets():
                  for reqs in extras.values() for req in reqs if "<" in req}
     assert held_back, "no upper bounds left in pyproject — drop the ignores"
     assert set(pip_entry("/")[2]) == held_back
+
+
+def limit_for(directory: str):
+    """The `open-pull-requests-limit` of the pip entry for `directory`, or None.
+
+    Parsed separately rather than by widening `entries()`, which several tests
+    unpack positionally.
+    """
+    seen = None
+    for line in CONFIG.read_text(encoding="utf-8").splitlines():
+        m = _ENTRY.match(line)
+        if m:
+            seen = {"eco": m.group(1)}
+            continue
+        if seen is None:
+            continue
+        m = _FIELD.match(line)
+        if not m:
+            continue
+        seen[m.group(1)] = m.group(2)
+        if seen.get("directory") == directory and seen["eco"] == "pip" \
+                and "open-pull-requests-limit" in seen:
+            return int(seen["open-pull-requests-limit"])
+    return None
+
+
+class TestNeitherPipEntryRegeneratesTheLock:
+    """Dependabot must not raise *version* updates for either pip entry.
+
+    Not a preference — it cannot regenerate the hash-pinned locks correctly. It
+    re-resolves on Linux and commits that resolution, dropping every pin whose
+    environment marker excludes it there, and the locks install with
+    --require-hashes on Windows and macOS too. `scripts/lock_toolchain.py`
+    resolves --universal for every supported platform, which is why it is the
+    source of truth (see its `-P` flag, and requirements/platform-pins.lock).
+
+    `open-pull-requests-limit: 0` disables version updates while leaving
+    **security** updates firing, which is what these entries are actually worth.
+    """
+
+    def test_the_requirements_entry_raises_no_version_prs(self):
+        assert limit_for("/requirements") == 0
+
+    def test_the_root_entry_raises_no_version_prs(self):
+        # The root entry cannot deliver what it was added for: every constraint
+        # under [project.optional-dependencies] is either an open lower bound or
+        # in its own ignore list, so the set of pyproject version updates it can
+        # ever produce is EMPTY — none of the eight PRs in the first scheduled
+        # run touched pyproject.toml. What it did produce was byte-identical
+        # duplicates of the /requirements entry's lock regenerations, which is
+        # the one thing that must never be merged.
+        assert limit_for("/") == 0
+
+    def test_both_pip_entries_still_exist(self):
+        # Deleting them would give up security updates too, which ignore the
+        # limit and are the coverage these entries genuinely provide.
+        assert pip_entry("/requirements")
+        assert pip_entry("/")

boost_skill_cli-1.0.305/tests/unit/test_workflow_concurrency.py

@@ -0,0 +1,112 @@
+"""Unit tests: superseded PR runs are cancelled, releases never are.
+
+Measured over six consecutive successful ``ci`` runs, **31%** of all job time
+was spent queueing rather than executing (104 job-minutes against 236). The
+median per-job queue swung 29x between runs — 0.1 min when the repo was quiet,
+2.9 min when a dozen ``loop/*`` branches and Dependabot PRs were live — so the
+cost is driven by concurrent footprint, not by the change under test. Sharding
+the mutation gate traded one runner slot for six and made that worse on purpose.
+
+``ci.yml`` is the largest workflow in the repo by a wide margin, and it was the
+only one with no ``concurrency`` group at all: every push to a pull request left
+the previous run's ~36 checks (six of them mutation shards) running to
+completion against nothing.
+
+The dangerous half of the fix is the half these tests pin. Cancelling a
+**pull_request** run that a newer push superseded costs nothing. Cancelling a
+**push to main** would abandon the run ``publish.yml`` gates the release on, and
+cancelling a **merge_group** run would leave a required check permanently
+unreported and deadlock the queue — the exact failure mode ci.yml's own comments
+describe. So cancellation must be conditional on the event, and that condition
+is what a future edit is most likely to get wrong.
+"""
+from __future__ import annotations
+
+import re
+from pathlib import Path
+
+import pytest
+
+WORKFLOWS = Path(__file__).resolve().parents[2] / ".github" / "workflows"
+CI = WORKFLOWS / "ci.yml"
+
+pytestmark = pytest.mark.skipif(
+    not CI.exists(),
+    reason=".github/workflows not reachable (e.g. mutation sandbox)")
+
+
+def concurrency_block(path: Path) -> str:
+    """The top-level ``concurrency:`` mapping of a workflow, or ''.
+
+    Top-level only: a job-level block is indented and must not be mistaken for
+    the workflow's own policy.
+    """
+    text = path.read_text(encoding="utf-8")
+    m = re.search(r"^concurrency:\s*$\n((?:^[ \t]+\S.*\n|^\s*#.*\n)*)", text, re.M)
+    return m.group(1) if m else ""
+
+
+class TestCiCancelsSupersededRuns:
+    def test_ci_declares_a_concurrency_group(self):
+        assert concurrency_block(CI), \
+            "ci.yml is the biggest workflow here; without a concurrency group " \
+            "every superseded push keeps ~36 checks running against nothing"
+
+    def test_the_group_is_per_pull_request(self):
+        # Keyed on the PR number so two PRs never cancel each other.
+        assert "github.event.pull_request.number" in concurrency_block(CI)
+
+    def test_non_pr_events_group_on_the_commit_not_the_ref(self):
+        # THE SUBTLE ONE. `cancel-in-progress: false` does not mean "never
+        # cancel" — it means a newer run waits, and GitHub cancels the older
+        # *pending* run when a third arrives. Keying main on `github.ref` puts
+        # every main push in one group, so three quick merges would leave a
+        # middle commit whose ci never completes; publish.yml fires on
+        # `workflow_run` of ci, so that commit would never release. A sha is
+        # unique per commit, so main and the merge queue never share a group.
+        block = concurrency_block(CI)
+        assert "github.sha" in block, block
+        assert "github.ref" not in block, \
+            "grouping non-PR runs on the ref can strand a main commit unreleased"
+
+    def test_cancellation_is_conditional_not_unconditional(self):
+        # `cancel-in-progress: true` would cancel main and merge_group runs too.
+        block = concurrency_block(CI)
+        m = re.search(r"cancel-in-progress:\s*(.+)", block)
+        assert m, "no cancel-in-progress in %r" % block
+        value = m.group(1).strip()
+        assert value not in ("true", "'true'", '"true"'), \
+            "unconditional cancel would abandon the run publish.yml gates on"
+        assert "pull_request" in value, value
+
+    def test_only_pull_request_events_are_cancelled(self):
+        # The whole safety property in one assertion: the guard names
+        # pull_request, so push-to-main and merge_group evaluate false.
+        value = re.search(r"cancel-in-progress:\s*(.+)",
+                          concurrency_block(CI)).group(1)
+        assert "github.event_name == 'pull_request'" in value, value
+
+
+class TestReleasePathIsNeverCancelled:
+    def test_publish_does_not_cancel_in_progress(self):
+        # Every merge to main cuts a PyPI release; cancelling a release run
+        # mid-upload is how you get a tagged version that never shipped.
+        block = concurrency_block(WORKFLOWS / "publish.yml")
+        assert "cancel-in-progress: false" in block, block
+
+    def test_no_workflow_cancels_a_merge_group_run(self):
+        # A required context whose run is cancelled never reports, and the
+        # merge queue waits on it forever. Any workflow that both triggers on
+        # merge_group and cancels unconditionally is that deadlock waiting to
+        # happen.
+        offenders = []
+        for path in sorted(WORKFLOWS.glob("*.yml")):
+            text = path.read_text(encoding="utf-8")
+            if not re.search(r"^\s*merge_group:", text, re.M):
+                continue
+            block = concurrency_block(path)
+            if re.search(r"cancel-in-progress:\s*true\s*$", block, re.M):
+                offenders.append(path.name)
+        assert not offenders, \
+            "these cancel merge_group runs and would deadlock the queue: %s" \
+            % ", ".join(offenders)

boost_skill_cli-1.0.303/docs/roadmap/items/ci-time-is-now-runner-queueing.md

@@ -1,40 +0,0 @@
----
-id: ci-time-is-now-runner-queueing
-board: code
-section: pipeline
-status: planned
-category: CI speed
-complexity: M
-impact: High
-wow: 4
-note: 104 job-min queued vs 236 executing — 31% of CI is waiting for a runner
-order: 62
-owner:
-pr:
-title: A third of CI job time is spent waiting for a runner, not running
----
-With the mutation gate no longer dominating, the largest remaining term in CI wall clock is
-<b>queueing</b>. Measured over six consecutive successful <code>ci</code> runs: <b>104
-job-minutes queued</b> against <b>236 job-minutes executing</b> &mdash; <b>31%</b> of all job
-time spent waiting for a runner.
-
-<b>The obvious metric lies.</b> A run's <code>run_started_at</code> minus
-<code>created_at</code> is <b>0.0 for every run</b>, which reads as "no queueing anywhere".
-Queueing happens per <em>job</em>, not per run, so it is only visible as
-<code>job.started_at - job.created_at</code>. Anything measuring this at run level will
-conclude, wrongly, that there is nothing to fix.
-
-The per-run spread shows what drives it &mdash; median job queue by run:
-<code>c36c53a7</code> 0.1&nbsp;min, <code>c15ed9da</code> 0.1, <code>903b704f</code> 0.2,
-<code>638bffeb</code> 0.7, <code>ad71ba99</code> <b>2.5</b>, <code>9e190537</code> <b>2.9</b>.
-That is a 29&times; swing driven not by the change under test but by how many sibling
-<code>loop/*</code> branches and Dependabot PRs happen to be live at the same moment. It is why
-one merge took <b>41 minutes</b> wall clock with a max shard of only 11.4.
-
-Sharding the mutation gate made this worse on purpose: it traded one runner slot for six. That
-is the right trade for latency in isolation, and the wrong one to keep making blindly while a
-dozen branches are in flight, because every concurrent PR now multiplies its footprint. Options,
-roughly in increasing order of intrusiveness: a <code>concurrency</code> group that cancels
-superseded PR runs; capping the shard matrix with <code>max-parallel</code>; or making the shard
-count adaptive. Worth measuring before choosing &mdash; this item is the measurement, not the
-fix.