boost-skill-cli 1.0.348__tar.gz → 1.0.349__tar.gz

{boost_skill_cli-1.0.348 → boost_skill_cli-1.0.349}/PKG-INFO

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

{boost_skill_cli-1.0.348 → boost_skill_cli-1.0.349}/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.348'
-__version_tuple__ = version_tuple = (1, 0, 348)
+__version__ = version = '1.0.349'
+__version_tuple__ = version_tuple = (1, 0, 349)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.348 → boost_skill_cli-1.0.349}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.0.348 → boost_skill_cli-1.0.349}/docs/roadmap/items/demo-cannot-open-its-own-pr.md

@@ -72,3 +72,18 @@ Nothing in the tree needed changing. Recording it as shipped rather than deletin
 card's analysis was right about <em>where</em> the blocker was: the earlier investigation had chased
 <code>demo.yml</code>'s own <code>permissions:</code> block, and the note that no edit to the workflow
 could fix a repository-level setting is what stopped that from being a long false lead.
+
+<b>Update &mdash; the repository setting this card called immovable has been turned on.</b> The API
+now reports <code>can_approve_pull_request_reviews: <b>true</b></code>, <code>demo.yml</code>
+succeeds on every push to <code>main</code>, and it has opened real pull requests as
+<code>github-actions[bot]</code> (<code>#353</code>, <code>#394</code>). So the coupled item
+[[scheduled-toolchain-lock-regeneration]] was unblocked too, and shipped on the strength of it.
+
+<b>What did not change is the check-run consequence</b>, which is worth keeping on the record
+because it is invisible: a PR opened this way lands with <b>zero</b> check runs, since
+<code>create-pull-request</code> pushes with <code>GITHUB_TOKEN</code> and a
+<code>GITHUB_TOKEN</code> push never triggers workflows. Measured on both bot PRs &mdash;
+<code>ffc07b0</code> and <code>a9da922</code> each had 0, and the same commits had 27 after an
+<i>Update branch</i>. An empty check list is indistinguishable from "CI has not started yet", so a
+bot PR can look ready to merge while nothing has run.
+

{boost_skill_cli-1.0.348 → boost_skill_cli-1.0.349}/docs/roadmap/items/scheduled-toolchain-lock-regeneration.md

@@ -2,12 +2,12 @@
 id: scheduled-toolchain-lock-regeneration
 board: code
 section: internals
-status: planned
+status: shipped
 category: Build · Gap
 complexity: M
 impact: Med
 wow: 2
-note: the toolchain lock now has no proactive update path — by choice, but nothing replaces it yet
+note: the blocker this card recorded had already been lifted — re-checked, not assumed
 order: 36
 owner:
 pr:
@@ -87,3 +87,42 @@ when the regenerated lock fails <code>lock_toolchain.py --check</code> on a runn
 untested scheduled workflow that opens PRs against <code>main</code> is worse than shipping nothing.
 The value of this note is that the next person picking it up starts from &ldquo;build it&rdquo;
 rather than from &ldquo;it cannot be built&rdquo;.
+
+<b>Shipped as <code>.github/workflows/lock-refresh.yml</code>, and the first thing that had to be
+re-checked was this card's own blocker.</b> It states the work is blocked because
+Actions&nbsp;&rarr;&nbsp;Workflow permissions forbids creating pull requests, citing
+<code>can_approve_pull_request_reviews: false</code>. That is no longer true: the API now returns
+<b><code>true</code></b>, <code>demo.yml</code> succeeds on every push to <code>main</code>, and it
+opened <code>#353</code> and <code>#394</code> as <code>github-actions[bot]</code>. A blocker
+recorded once is a claim with an expiry date; this one had quietly lapsed, and the card would have
+kept the item shelved indefinitely.
+
+<b>One PR for all five groups &mdash; a deliberate departure from what this card proposed.</b> The
+card suggested per-group jobs so a bump stays reviewable. Two things measured while building it
+argue the other way. <code>lock_toolchain.py</code> has <b>no per-group flag</b>
+(<code>--upgrade</code> always re-resolves all five), so a five-job matrix would run the same
+resolution five times and commit one file from each. And a PR opened this way arrives with
+<b>zero check runs</b> &mdash; <code>create-pull-request</code> pushes with
+<code>GITHUB_TOKEN</code>, which never triggers workflows &mdash; so every one of them costs a human
+a manual <i>Update branch</i> before CI reports at all. Five PRs a month is five full CI runs and
+five manual unblocks to review what is usually a list of version bumps. Reviewability is bought
+instead with a <b>monthly</b> cadence and a per-group diffstat in the PR body.
+
+<b>The other three constraints this card named were met as written.</b> <code>uv</code> and the
+network are provisioned the same way <code>ci.yml</code> does it (<code>pip install uv</code>, then
+the script). <code>--audit</code> runs as its own invocation, because the script refuses it
+alongside <code>--upgrade</code> &mdash; auditing a file mid-replacement reads the old bytes &mdash;
+and a failure there means no PR is opened. Every <code>uses:</code> is pinned to the same peeled
+SHAs the repo already uses, permissions are <code>contents: read</code> at the top with the two
+writes scoped to the one job, and no <code>merge_group:</code> trigger is needed because this is not
+a required context (<code>check_required_checks.py</code> passes).
+
+<b>Verified before pushing:</b> the workflow parses, and <code>zizmor</code> reports <b>no
+findings</b>. That clean result was itself checked rather than trusted &mdash; re-running the
+scanner against a copy with <code>${{ github.event.head_commit.message }}</code> spliced into a
+<code>run:</code> block produces a high-severity <code>template-injection</code>, so the scanner is
+genuinely reading this file. That check exists because an earlier workflow in this repo
+(<code>shards.yml</code>) shipped exactly that hole.
+
+<b>Unproven until it runs:</b> the first scheduled execution is the first end-to-end exercise.
+

{boost_skill_cli-1.0.348 → boost_skill_cli-1.0.349}/docs/roadmap.html

@@ -1806,8 +1806,9 @@ validator that rejects values below 1; reuse it here.</p></details>
       </article>
 
       <article class="cap rcard" id="scheduled-toolchain-lock-regeneration">
-        <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>The toolchain lock has no proactive update path any more</h3>
+        <details class="cardbody"><summary>Write-up</summary>
         <p><code>#342</code> set <code>open-pull-requests-limit: 0</code> on the <code>/requirements</code>
 Dependabot entry, because Dependabot cannot regenerate a hash-pinned universal lock without dropping
 the pins whose environment markers exclude them on the resolving platform (see
@@ -1881,12 +1882,50 @@ Deliberately left unimplemented here. It needs a real decision about cadence and
 when the regenerated lock fails <code>lock_toolchain.py --check</code> on a runner, and shipping an
 untested scheduled workflow that opens PRs against <code>main</code> is worse than shipping nothing.
 The value of this note is that the next person picking it up starts from &ldquo;build it&rdquo;
-rather than from &ldquo;it cannot be built&rdquo;.</p>
+rather than from &ldquo;it cannot be built&rdquo;.
+
+<b>Shipped as <code>.github/workflows/lock-refresh.yml</code>, and the first thing that had to be
+re-checked was this card's own blocker.</b> It states the work is blocked because
+Actions&nbsp;&rarr;&nbsp;Workflow permissions forbids creating pull requests, citing
+<code>can_approve_pull_request_reviews: false</code>. That is no longer true: the API now returns
+<b><code>true</code></b>, <code>demo.yml</code> succeeds on every push to <code>main</code>, and it
+opened <code>#353</code> and <code>#394</code> as <code>github-actions[bot]</code>. A blocker
+recorded once is a claim with an expiry date; this one had quietly lapsed, and the card would have
+kept the item shelved indefinitely.
+
+<b>One PR for all five groups &mdash; a deliberate departure from what this card proposed.</b> The
+card suggested per-group jobs so a bump stays reviewable. Two things measured while building it
+argue the other way. <code>lock_toolchain.py</code> has <b>no per-group flag</b>
+(<code>--upgrade</code> always re-resolves all five), so a five-job matrix would run the same
+resolution five times and commit one file from each. And a PR opened this way arrives with
+<b>zero check runs</b> &mdash; <code>create-pull-request</code> pushes with
+<code>GITHUB_TOKEN</code>, which never triggers workflows &mdash; so every one of them costs a human
+a manual <i>Update branch</i> before CI reports at all. Five PRs a month is five full CI runs and
+five manual unblocks to review what is usually a list of version bumps. Reviewability is bought
+instead with a <b>monthly</b> cadence and a per-group diffstat in the PR body.
+
+<b>The other three constraints this card named were met as written.</b> <code>uv</code> and the
+network are provisioned the same way <code>ci.yml</code> does it (<code>pip install uv</code>, then
+the script). <code>--audit</code> runs as its own invocation, because the script refuses it
+alongside <code>--upgrade</code> &mdash; auditing a file mid-replacement reads the old bytes &mdash;
+and a failure there means no PR is opened. Every <code>uses:</code> is pinned to the same peeled
+SHAs the repo already uses, permissions are <code>contents: read</code> at the top with the two
+writes scoped to the one job, and no <code>merge_group:</code> trigger is needed because this is not
+a required context (<code>check_required_checks.py</code> passes).
+
+<b>Verified before pushing:</b> the workflow parses, and <code>zizmor</code> reports <b>no
+findings</b>. That clean result was itself checked rather than trusted &mdash; re-running the
+scanner against a copy with <code>${{ github.event.head_commit.message }}</code> spliced into a
+<code>run:</code> block produces a high-severity <code>template-injection</code>, so the scanner is
+genuinely reading this file. That check exists because an earlier workflow in this repo
+(<code>shards.yml</code>) shipped exactly that hole.
+
+<b>Unproven until it runs:</b> the first scheduled execution is the first end-to-end exercise.</p></details>
         <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">the toolchain lock now has no proactive update path — by choice, but nothing replaces it yet</span>
+          <span class="m">the blocker this card recorded had already been lifted — re-checked, not assumed</span>
         </div>
       </article>
 
@@ -3713,7 +3752,21 @@ this card says is impossible.
 Nothing in the tree needed changing. Recording it as shipped rather than deleting it, because the
 card's analysis was right about <em>where</em> the blocker was: the earlier investigation had chased
 <code>demo.yml</code>'s own <code>permissions:</code> block, and the note that no edit to the workflow
-could fix a repository-level setting is what stopped that from being a long false lead.</p></details>
+could fix a repository-level setting is what stopped that from being a long false lead.
+
+<b>Update &mdash; the repository setting this card called immovable has been turned on.</b> The API
+now reports <code>can_approve_pull_request_reviews: <b>true</b></code>, <code>demo.yml</code>
+succeeds on every push to <code>main</code>, and it has opened real pull requests as
+<code>github-actions[bot]</code> (<code>#353</code>, <code>#394</code>). So the coupled item
+[[scheduled-toolchain-lock-regeneration]] was unblocked too, and shipped on the strength of it.
+
+<b>What did not change is the check-run consequence</b>, which is worth keeping on the record
+because it is invisible: a PR opened this way lands with <b>zero</b> check runs, since
+<code>create-pull-request</code> pushes with <code>GITHUB_TOKEN</code> and a
+<code>GITHUB_TOKEN</code> push never triggers workflows. Measured on both bot PRs &mdash;
+<code>ffc07b0</code> and <code>a9da922</code> each had 0, and the same commits had 27 after an
+<i>Update branch</i>. An empty check list is indistinguishable from "CI has not started yet", so a
+bot PR can look ready to merge while nothing has run.</p></details>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Med</b></span>