boost-skill-cli 1.2.6__tar.gz → 1.2.8__tar.gz

{boost_skill_cli-1.2.6 → boost_skill_cli-1.2.8}/PKG-INFO

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

{boost_skill_cli-1.2.6 → boost_skill_cli-1.2.8}/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.6'
-__version_tuple__ = version_tuple = (1, 2, 6)
+__version__ = version = '1.2.8'
+__version_tuple__ = version_tuple = (1, 2, 8)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.6 → boost_skill_cli-1.2.8}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.2.6 → boost_skill_cli-1.2.8}/boost_skill_cli.egg-info/SOURCES.txt

@@ -412,8 +412,10 @@ docs/roadmap/items/sync-reported-success-for-a-link-it-refused.md
 docs/roadmap/items/tap-signing-and-provenance-sigstore-minisign.md
 docs/roadmap/items/taps-check-out-freight-they-never-index.md
 docs/roadmap/items/the-catalogue-advertised-repos-that-no-longer-exist.md
+docs/roadmap/items/the-shard-job-that-could-not-finish.md
 docs/roadmap/items/theme-asset-linting-stylelint-eslint.md
 docs/roadmap/items/tool-call-eval-tier.md
+docs/roadmap/items/two-ci-controls-that-could-not-act.md
 docs/roadmap/items/two-crashes-that-should-have-been-messages.md
 docs/roadmap/items/typo-detection-codespell.md
 docs/roadmap/items/typosquat-and-name-confusion-detection.md

boost_skill_cli-1.2.8/docs/roadmap/items/the-shard-job-that-could-not-finish.md

@@ -0,0 +1,46 @@
+---
+id: the-shard-job-that-could-not-finish
+board: code
+section: internals
+status: shipped
+category: CI · Performance
+complexity: S
+impact: High
+wow: 5
+note: 5h30m cancelled at the ceiling, then 2h07m green — the same job, with duplicate embeddings collapsed
+order: 120
+owner: docs/shards-measured-scale
+pr: 531
+title: the shard job that had never once finished, and the timeout that could not be raised
+---
+<b><code>shards</code> exists so a keyless user gets semantic search without paying to embed the
+catalogue themselves</b> &mdash; embedding is ~1.2 s/chunk on CPU, importing the same rows is 0.12 s,
+so without published shards the keyless tier is available in principle and unreachable in practice.
+It had <b>never once produced an artifact</b>.
+
+<b>Two mechanisms, in order.</b> The first was a matrix built by splitting
+<code>taps.txt</code> on whitespace &mdash; rows are <code>repo &lt;sha&gt; &lt;count&gt;</code>, so
+20 registries became 60 jobs, and the run log is full of <code>build (18)</code> and
+<code>build (b29e7cf6…)</code>. That was fixed. The <em>next</em> scheduled run then had one job
+left that could not finish: <code>sickn33/antigravity-awesome-skills</code> burned its entire
+<code>timeout-minutes: 330</code> and was cancelled, having published nothing.
+
+<b>Raising the timeout was never on the table.</b> GitHub's job ceiling is 6 hours and 330 minutes is
+already under it. So the workflow's own scale note &mdash; &ldquo;the largest pinned tap is ~75
+min&rdquo; &mdash; was not a stale estimate to nudge upward; it was wrong about the shape of the
+problem.
+
+<b>The measurement that changed the answer.</b> That registry is 6,309 entries and 77,423 chunks
+&mdash; of which only <b>24,246 are distinct</b>. <b>68.7% are byte-identical repeats</b>, because the
+registry vendors its own items many times over. Embeddings are deterministic, so every copy was
+bought at full price for the same vector, and <code>retrieve_any</code> discards the copies anyway.
+
+<b>Same job, 5 h 30 m cancelled &rarr; 2 h 07 m green.</b> With the duplicate embedding work collapsed
+(the catalogue content-identity change), the job completed and uploaded a <b>129 MB shard carrying
+78,095 chunks</b>. Nothing about the output shrank &mdash; one row per entry-chunk is what keeps tap
+deletion correct; only the number of times the provider was asked did.
+
+<b>The lesson is where the budget lives.</b> A per-registry cost estimate keyed on entry count is
+measuring the wrong thing: a registry that mirrors itself heavily is far cheaper than its size
+suggests, and one that does not is the case to watch against the ceiling. The workflow now says so,
+with the numbers.

boost_skill_cli-1.2.8/docs/roadmap/items/two-ci-controls-that-could-not-act.md

@@ -0,0 +1,50 @@
+---
+id: two-ci-controls-that-could-not-act
+board: code
+section: internals
+status: shipped
+category: CI · Correctness
+complexity: S
+impact: Medium
+wow: 4
+note: one publisher could never publish and one alert could never stand down — both reported success
+order: 119
+owner: fix/ci-controls-that-cannot-act
+pr: 529
+title: a publisher that could not publish, and an alert that could not stand down
+---
+<b>Two controls, the same failure mode: present, running, and structurally unable to do the thing
+they exist for.</b>
+
+<b>1. <code>eval-stats</code> pushed to a branch no token can push to.</b> An earlier fix got the
+credentials right &mdash; the checkout uses <code>persist-credentials: false</code>, so the push
+needed its own token URL, and it got one. That took the workflow as far as a <em>different</em>
+permanent failure: <code>GH013: Repository rule violations found for refs/heads/main</code>.
+<code>main</code> carries a ruleset with a <code>pull_request</code> rule and an <b>empty bypass
+list</b>, so no token can push to it &mdash; not <code>github.token</code>, not a PAT, not any bot.
+The workflow was not misconfigured; it was impossible.
+
+<b>The remedy is not a bypass actor.</b> Adding one would open the protection guarding every change
+to main so that a docs payload can skip review. The refreshed metrics now arrive the way
+<code>eval-corpus-refresh.yml</code> already lands its moved pins &mdash; as a pull request on one
+long-lived <code>bot/eval-metrics</code> branch that each run updates in place, rather than a new PR
+a week. Reviewable, mergeable, and no weaker than any other change to main. It carries the same
+warning that workflow's PRs do: a <code>GITHUB_TOKEN</code> push never triggers workflows, so the
+check list is empty until someone presses <b>Update branch</b>, and empty looks exactly like
+&ldquo;not started yet&rdquo;.
+
+<b>2. The failure tracker opened issues and never closed one.</b> Its own closing line said
+&ldquo;close this once CI is green again&rdquo; &mdash; a manual step nobody had a reason to take. So
+<code>visual</code> stayed open through <b>four consecutive green runs</b>, and an issue list that
+mixes live outages with fixed ones makes every entry in it read as equally suspect. An alert that
+cannot stand down is only half an alert. A success on main now closes the tracker for
+<em>that</em> workflow, keyed on the same per-workflow marker the opener writes &mdash; a
+<code>ci</code> success must never close a <code>demo</code> tracker.
+
+<b>The second job is what made the permissions wrong.</b> <code>issues: write</code> sat at the
+workflow level, where it reaches every job including any added later; zizmor's excessive-permissions
+audit says so and now fails the build on it. Each job asks for its own.
+
+<b>Both halves are pinned statically</b>, and the push guard was verified by reversion: restore the
+old <code>HEAD:main</code> and the test names the exact line. The guard outlives this fix &mdash; it
+is parametrised over every workflow that pushes, so the next one cannot rediscover the same wall.

{boost_skill_cli-1.2.6 → boost_skill_cli-1.2.8}/docs/roadmap.html

@@ -133,7 +133,7 @@
       <div class="stat"><b>16</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>7</b><span>Planned</span></div>
-      <div class="stat"><b>256</b><span>Loop finds</span></div>
+      <div class="stat"><b>258</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -4165,6 +4165,96 @@ both, which means the no-atheris seed smoke &mdash; the path that runs without t
           <span class="m">the weekly fuzzer has now found two crashes in one function, three weeks apart, and been ignored both times</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="two-ci-controls-that-could-not-act">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI · Correctness</span></div>
+        <h3>a publisher that could not publish, and an alert that could not stand down</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><b>Two controls, the same failure mode: present, running, and structurally unable to do the thing
+they exist for.</b>
+
+<b>1. <code>eval-stats</code> pushed to a branch no token can push to.</b> An earlier fix got the
+credentials right &mdash; the checkout uses <code>persist-credentials: false</code>, so the push
+needed its own token URL, and it got one. That took the workflow as far as a <em>different</em>
+permanent failure: <code>GH013: Repository rule violations found for refs/heads/main</code>.
+<code>main</code> carries a ruleset with a <code>pull_request</code> rule and an <b>empty bypass
+list</b>, so no token can push to it &mdash; not <code>github.token</code>, not a PAT, not any bot.
+The workflow was not misconfigured; it was impossible.
+
+<b>The remedy is not a bypass actor.</b> Adding one would open the protection guarding every change
+to main so that a docs payload can skip review. The refreshed metrics now arrive the way
+<code>eval-corpus-refresh.yml</code> already lands its moved pins &mdash; as a pull request on one
+long-lived <code>bot/eval-metrics</code> branch that each run updates in place, rather than a new PR
+a week. Reviewable, mergeable, and no weaker than any other change to main. It carries the same
+warning that workflow's PRs do: a <code>GITHUB_TOKEN</code> push never triggers workflows, so the
+check list is empty until someone presses <b>Update branch</b>, and empty looks exactly like
+&ldquo;not started yet&rdquo;.
+
+<b>2. The failure tracker opened issues and never closed one.</b> Its own closing line said
+&ldquo;close this once CI is green again&rdquo; &mdash; a manual step nobody had a reason to take. So
+<code>visual</code> stayed open through <b>four consecutive green runs</b>, and an issue list that
+mixes live outages with fixed ones makes every entry in it read as equally suspect. An alert that
+cannot stand down is only half an alert. A success on main now closes the tracker for
+<em>that</em> workflow, keyed on the same per-workflow marker the opener writes &mdash; a
+<code>ci</code> success must never close a <code>demo</code> tracker.
+
+<b>The second job is what made the permissions wrong.</b> <code>issues: write</code> sat at the
+workflow level, where it reaches every job including any added later; zizmor's excessive-permissions
+audit says so and now fails the build on it. Each job asks for its own.
+
+<b>Both halves are pinned statically</b>, and the push guard was verified by reversion: restore the
+old <code>HEAD:main</code> and the test names the exact line. The guard outlives this fix &mdash; it
+is parametrised over every workflow that pushes, so the next one cannot rediscover the same wall.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Medium</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">one publisher could never publish and one alert could never stand down — both reported success</span>
+        </div>
+      </article>
+
+      <article class="cap rcard" id="the-shard-job-that-could-not-finish">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI · Performance</span></div>
+        <h3>the shard job that had never once finished, and the timeout that could not be raised</h3>
+        <details class="cardbody"><summary>Write-up</summary>
+        <p><b><code>shards</code> exists so a keyless user gets semantic search without paying to embed the
+catalogue themselves</b> &mdash; embedding is ~1.2 s/chunk on CPU, importing the same rows is 0.12 s,
+so without published shards the keyless tier is available in principle and unreachable in practice.
+It had <b>never once produced an artifact</b>.
+
+<b>Two mechanisms, in order.</b> The first was a matrix built by splitting
+<code>taps.txt</code> on whitespace &mdash; rows are <code>repo &lt;sha&gt; &lt;count&gt;</code>, so
+20 registries became 60 jobs, and the run log is full of <code>build (18)</code> and
+<code>build (b29e7cf6…)</code>. That was fixed. The <em>next</em> scheduled run then had one job
+left that could not finish: <code>sickn33/antigravity-awesome-skills</code> burned its entire
+<code>timeout-minutes: 330</code> and was cancelled, having published nothing.
+
+<b>Raising the timeout was never on the table.</b> GitHub's job ceiling is 6 hours and 330 minutes is
+already under it. So the workflow's own scale note &mdash; &ldquo;the largest pinned tap is ~75
+min&rdquo; &mdash; was not a stale estimate to nudge upward; it was wrong about the shape of the
+problem.
+
+<b>The measurement that changed the answer.</b> That registry is 6,309 entries and 77,423 chunks
+&mdash; of which only <b>24,246 are distinct</b>. <b>68.7% are byte-identical repeats</b>, because the
+registry vendors its own items many times over. Embeddings are deterministic, so every copy was
+bought at full price for the same vector, and <code>retrieve_any</code> discards the copies anyway.
+
+<b>Same job, 5 h 30 m cancelled &rarr; 2 h 07 m green.</b> With the duplicate embedding work collapsed
+(the catalogue content-identity change), the job completed and uploaded a <b>129 MB shard carrying
+78,095 chunks</b>. Nothing about the output shrank &mdash; one row per entry-chunk is what keeps tap
+deletion correct; only the number of times the provider was asked did.
+
+<b>The lesson is where the budget lives.</b> A per-registry cost estimate keyed on entry count is
+measuring the wrong thing: a registry that mirrors itself heavily is far cheaper than its size
+suggests, and one that does not is the case to watch against the ceiling. The workflow now says so,
+with the numbers.</p></details>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★★</b></span>
+          <span class="m">5h30m cancelled at the ceiling, then 2h07m green — the same job, with duplicate embeddings collapsed</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.2.6 → boost_skill_cli-1.2.8}/tests/unit/test_failure_alerting_covers_unattended.py

@@ -130,3 +130,47 @@ class TestEveryUnattendedWorkflowIsWatched:
         names = {workflow_name(p.read_text(encoding="utf-8"), p.stem)
                  for p in WORKFLOWS.glob("*.yml")}
         assert watched() <= names, sorted(watched() - names)
+
+
+class TestTheAlertCanStandDown:
+    """An alert that cannot close is only half an alert.
+
+    The tracker opened issues, commented on repeats, and never closed one — so
+    its own closing line, "close this once CI is green again", was a manual step
+    nobody had a reason to take. `visual` stayed open through four consecutive
+    green runs, and a list that mixes live outages with fixed ones makes every
+    entry in it read as equally suspect.
+    """
+
+    def test_a_success_on_main_closes_the_tracker(self):
+        text = ALERT.read_text(encoding="utf-8")
+        assert "conclusion == 'success'" in text, (
+            "nothing reacts to a watched workflow going green, so every "
+            "tracker this file opens stays open until someone closes it")
+        assert "state: 'closed'" in text
+
+    def test_closing_is_keyed_by_workflow_like_opening(self):
+        """A `ci` success must not close a `demo` tracker.
+
+        The opener keys its marker on the workflow name for exactly this
+        reason; a closer that matched any `ci-failure` issue would undo that.
+        """
+        text = ALERT.read_text(encoding="utf-8")
+        assert text.count("ci-failure-tracker:${run.name}") >= 2, (
+            "the closing half must use the same per-workflow marker the "
+            "opening half writes")
+
+    def test_only_main_can_close_it(self):
+        """`workflow_run` fires for the default branch, but the opener still
+        checks — and an asymmetry here would let a non-main success close a
+        tracker for a failure that is still live on main."""
+        text = ALERT.read_text(encoding="utf-8")
+        assert text.count("head_branch == 'main'") >= 2
+
+    def test_permissions_are_not_granted_workflow_wide(self):
+        """`issues: write` at the top reaches every job, including any added
+        later. zizmor's excessive-permissions audit fails the build on it."""
+        text = ALERT.read_text(encoding="utf-8")
+        assert re.search(r"^permissions:\s*\{\}\s*$", text, re.M), \
+            "workflow-level permissions must be empty; each job asks for its own"
+        assert text.count("issues: write") >= 2

{boost_skill_cli-1.2.6 → boost_skill_cli-1.2.8}/tests/unit/test_workflow_push_has_credentials.py

@@ -85,6 +85,46 @@ class TestTheGuardCanActuallySee:
         assert _AUTHED_PUSH.search(join_continuations(wrapped))
 
 
+#: `HEAD:main`, `HEAD:refs/heads/main`, or a bare push whose refspec is main.
+_PUSHES_TO_MAIN = re.compile(r"git push[^\n]*\b(HEAD|[\w./-]+):(refs/heads/)?main\b")
+
+
+class TestNothingPushesToMain:
+    """Credentials were only the first layer; the branch is the second.
+
+    Fixing the missing token got `eval-stats` as far as a *different* permanent
+    failure — `GH013: Repository rule violations found for refs/heads/main`.
+    main carries a ruleset with a `pull_request` rule and an **empty bypass
+    list**, so no token can push to it: not `github.token`, not a PAT, not any
+    bot. A workflow that pushes there is not misconfigured, it is impossible.
+
+    The remedy is never to add a bypass actor. That would open the protection
+    guarding every change to main so a docs payload can skip review. `ci.yml`
+    pushes `badges:badges` and `eval-stats.yml` now pushes `eval-metrics`;
+    merging either into main stays a pull request, like everything else.
+    """
+
+    def test_the_guard_recognises_a_push_to_main(self):
+        for line in ("git push -q origin HEAD:main",
+                     'git push -q "https://x@github.com/o/r" HEAD:refs/heads/main',
+                     "git push origin main:main"):
+            assert _PUSHES_TO_MAIN.search(line), line
+
+    def test_the_guard_does_not_flag_a_side_branch(self):
+        for line in ("git push -qf origin badges:badges",
+                     'git push -qf "https://x@github.com/o/r" HEAD:eval-metrics'):
+            assert not _PUSHES_TO_MAIN.search(line), line
+
+    @pytest.mark.parametrize("name", sorted(pushing_workflows()))
+    def test_no_workflow_pushes_to_main(self, name):
+        hits = [line.strip() for line in pushing_workflows()[name].splitlines()
+                if _PUSHES_TO_MAIN.search(line)]
+        assert not hits, (
+            "%s pushes to main, which main's ruleset forbids for every token "
+            "(GH013). Push to a side branch and open a pull request; do NOT "
+            "add a bypass actor to the ruleset: %s" % (name, hits))
+
+
 @pytest.mark.parametrize("name", sorted(pushing_workflows()))
 def test_a_push_after_an_unpersisted_checkout_carries_a_token(name):
     text = pushing_workflows()[name]