boost-skill-cli 1.0.330__tar.gz → 1.0.332__tar.gz

{boost_skill_cli-1.0.330/boost_skill_cli.egg-info → boost_skill_cli-1.0.332}/PKG-INFO

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

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/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.330'
-__version_tuple__ = version_tuple = (1, 0, 330)
+__version__ = version = '1.0.332'
+__version_tuple__ = version_tuple = (1, 0, 332)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/docs/roadmap/items/code-scanning-rule-can-be-restored.md

@@ -2,7 +2,7 @@
 id: code-scanning-rule-can-be-restored
 board: code
 section: trust
-status: planned
+status: shipped
 category: Release safety
 complexity: S
 impact: Med
@@ -45,3 +45,19 @@ path filters and runs on <code>push</code>, <code>pull_request</code> and
 repo has hit twice. And it catches something the status check does not &mdash;
 <code>codeql-analyze</code> passes when the <em>job</em> succeeds, including when it succeeds
 having found error-severity alerts.
+
+<b>Done &mdash; the rule is back, and scoped exactly as this card prescribed.</b> Read from the live
+<code>main</code> ruleset (id <code>19130332</code>): it carries a <code>code_scanning</code> rule
+whose <code>code_scanning_tools</code> list is <b><code>CodeQL</code> alone</b>, at
+<code>security_alerts_threshold: high_or_higher</code> and <code>alerts_threshold: errors</code>.
+Scorecard is not in the list, which is the single decision this card exists to get right.
+
+The safety precondition still holds and was re-checked rather than assumed: <b>CodeQL has 0 open
+alerts</b>, while Scorecard has <b>4 open</b> (down from the 7 recorded above), every one still a
+posture metric that must not be dismissed. Had Scorecard been added to that tool list, those four
+would block every merge in the repository immediately &mdash; the failure mode this card correctly
+identifies as the reason the work looked blocked.
+
+No change was needed. Recording it as shipped so the board stops advertising work that is already
+in place, and so the tool-list constraint stays written down: anyone re-editing this rule through the
+GitHub UI will be offered Scorecard right next to CodeQL in the picker.

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

@@ -2,7 +2,7 @@
 id: demo-cannot-open-its-own-pr
 board: code
 section: pipeline
-status: planned
+status: shipped
 category: CI reporting
 complexity: S
 impact: Med
@@ -61,3 +61,14 @@ that job cannot open a pull request either. So this toggle now gates two items r
 the second is a supply-chain freshness gap rather than a docs asset. That does not make the
 decision automatic, but it does change what is on each side of it.
 
+
+<b>Unblocked, and already working &mdash; the setting was flipped.</b> This card's blocker is
+<code>can_approve_pull_request_reviews: false</code>. The API now reports it as <b><code>true</code></b>,
+and the effect is visible rather than theoretical: <code>demo.yml</code>'s recent runs are green, and
+<b>PR <code>#353</code> was opened by <code>github-actions[bot]</code></b> &mdash; the exact action
+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.

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/docs/roadmap/items/mcp-check-skills-before-starting-a-task.md

@@ -2,14 +2,14 @@
 id: mcp-check-skills-before-starting-a-task
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Interop · Adoption
 complexity: S
 impact: High
 wow: 3
 note: agent reflex
 order: 64
-owner: mcp-task-entrance
+owner:
 pr: 318
 title: MCP — check for a skill when a task starts, not only when authoring one
 ---
@@ -28,3 +28,16 @@ check. A closing proportion note bounds it, because an unbounded <em>always chec
 turns every trivial turn into a tool call and an agent that learns to ignore the guidance
 ignores all of it. Both triggers and the bound are pinned by tests, so dropping either
 regresses.
+
+<b>Shipped &mdash; the claim was stale, not the work.</b> PR <code>#318</code> merged and its branch
+is gone, but this item sat at <code>inflight</code> under that branch name, so the board advertised
+live work as taken. Verified against the code rather than the PR state alone:
+<code>mcp.INSTRUCTIONS</code> leads with using an installed skill, names <code>boost_list</code> for
+what is usable right now, and carries the proportion bound this card asks for &mdash; &ldquo;Skip it
+for a question, a one-line edit, or a command you were just handed.&rdquo; The trigger is pinned by
+<code>test_instructions_lead_with_using_a_skill_not_authoring_one</code>.
+
+One note for anyone reading both cards: <code>mcp-one-benefit-nameable-task</code> (<code>#355</code>,
+later) <em>superseded</em> this card's &ldquo;two declared triggers&rdquo; framing by demoting
+authoring to a clause on <code>boost_search</code>, on the grounds that it was the rarer moment
+crowding out the common one. The task-start trigger this card argued for is what survived.

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/docs/roadmap/items/mcp-one-benefit-nameable-task.md

@@ -2,14 +2,14 @@
 id: mcp-one-benefit-nameable-task
 board: code
 section: dx
-status: inflight
+status: shipped
 category: Interop · Adoption
 complexity: S
 impact: High
 wow: 3
 note: agent reflex
 order: 74
-owner: loop/mcp-nameable-task
+owner:
 pr: 355
 title: MCP — one benefit, one observable trigger (and stop routing through boost_info)
 ---
@@ -42,3 +42,11 @@ so the hop bought a round-trip and a decision point and nothing else. It stays r
 for looking up a name from elsewhere, and its description now says so. All of it is
 pinned by tests, including negative assertions so authoring and the info hop cannot
 creep back.
+
+<b>Shipped &mdash; the claim was stale, not the work.</b> PR <code>#355</code> merged and its branch
+is gone, yet this item still read as owned. Every element is verifiable in
+<code>mcp.INSTRUCTIONS</code> today: the stated cost (&ldquo;read-only, take about a second, and
+install nothing&rdquo;), the miss protocol (&ldquo;Finding nothing is a good outcome, not a wasted
+call&rdquo;), &ldquo;The task stays yours&rdquo;, and <code>boost_info</code> absent from the
+advertised flow &mdash; which <code>test_instructions_route_search_straight_to_install</code> pins
+with a negative assertion so the hop cannot creep back.

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/docs/roadmap/items/merged-loop-branches-are-never-pruned.md

@@ -2,7 +2,7 @@
 id: merged-loop-branches-are-never-pruned
 board: code
 section: pipeline
-status: planned
+status: shipped
 category: Hygiene · DX
 complexity: S
 impact: Low
@@ -45,3 +45,26 @@ Low impact and near-zero risk to fix &mdash; flip <code>delete_branch_on_merge</
 the backlog can be pruned by listing merged PR head refs. The reason it is worth doing at all is
 that CLAUDE.md tells every agent to run <code>git worktree list</code> and inspect branch state
 before touching a tree, and 68 stale entries make that check noisier for every concurrent loop.
+
+<b>Shipped &mdash; and the premise had gone stale, which is why it was worth re-checking rather than
+assuming.</b> This card's core claim is that <code>delete_branch_on_merge</code> is <code>false</code>.
+It is now <b><code>true</code></b>, and the backlog it describes is gone: against the card's
+<b>77 branches, 70 of them <code>loop/*</code></b>, the repository today carries <b>5 branches, 2
+<code>loop/*</code></b>.
+
+Two stragglers predating the setting change were still present and are now deleted:
+<code>evals-harness</code> (PR <code>#317</code>, merged) and <code>mcp-task-entrance</code>
+(PR <code>#318</code>, merged). Both were classified the way this card insists on &mdash; by
+<b>pull-request state</b>, not commit reachability &mdash; because the squash-merge point above is
+real: <code>compare(main...branch).ahead_by</code> reports every merged branch as permanently ahead,
+so reachability would have reported 0 of them deletable.
+
+Three branches remain and are deliberately <em>not</em> deleted: <code>bot/demo-gif</code> has an
+open PR (<code>#353</code>), and <code>badges</code>, <code>loop/keyless-card-dedupe</code> and
+<code>loop/sbom-in-release-job</code> have <b>no PR on record</b>. A branch with no PR cannot be shown
+to be merged, and deleting it could destroy unmerged work &mdash; so the safe rule is to leave it for
+a human, which is also why no automated pruner is proposed here.
+
+<b>No automation was added.</b> The repository setting does the job going forward; a workflow that
+deleted branches on a schedule would add a way to lose work in exchange for tidying a list that is
+now five entries long.

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/docs/roadmap/items/pytest-tmpdir-cve-blocked-by-py39-floor.md

@@ -2,7 +2,7 @@
 id: pytest-tmpdir-cve-blocked-by-py39-floor
 board: code
 section: pipeline
-status: planned
+status: declined
 category: Supply chain
 complexity: M
 impact: Low
@@ -34,3 +34,18 @@ Revisit when either the 3.9 floor is dropped or a patched 8.x lands. If the floo
 and the alert must clear, the real mitigation is pointing pytest at a private base
 temp dir (<code>--basetemp</code> / <code>PYTEST_DEBUG_TEMPROOT</code>) so the predictable
 path is never used — that fixes the behaviour without satisfying Dependabot's version check.
+
+<b>Declined &mdash; recorded as a decision rather than left to look like pending work.</b> The
+alert is already dismissed upstream as <code>tolerable_risk</code>; leaving the card
+<code>planned</code> made the board advertise work that nobody intends to do and that no code change
+could complete.
+
+The revisit condition was re-checked rather than assumed: this card says revisit &ldquo;when either
+the 3.9 floor is dropped or a patched 8.x lands&rdquo;. PyPI's latest 8.x is still
+<b><code>8.4.2</code></b> &mdash; no <code>8.4.3</code>, no <code>8.5</code> &mdash; and the advisory
+marks every 8.x vulnerable, so there is nothing to move to. The 3.9 floor is a deliberate
+compatibility promise in <code>pyproject.toml</code>, not an oversight.
+
+Reopen this if either condition changes. The residual exposure is unchanged and remains
+contributor-facing only: <code>[project].dependencies</code> is empty, so nobody installing
+<code>boost-skill-cli</code> ever receives pytest.

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/docs/roadmap/items/scheduled-toolchain-lock-regeneration.md

@@ -71,3 +71,19 @@ normal PR gate once a human opens it.
 Either way the freshness gap this item exists to close narrows from "nobody is watching" to "a
 human clicks a button", which is the honest available improvement while the setting stands.
 
+
+<b>The blocker is gone.</b> This card is gated on the same repository setting as
+<code>demo-cannot-open-its-own-pr</code>, and the API now reports
+<code>can_approve_pull_request_reviews: <b>true</b></code>. Confirmed working rather than merely
+configured: <code>#353</code> was opened by <code>github-actions[bot]</code>.
+
+So the &ldquo;honest available improvement while the setting stands&rdquo; compromise described above
+&mdash; a workflow that only reports drift and waits for a human to click a button &mdash; is no
+longer the ceiling. A scheduled job can now regenerate the lock and open its own PR, which is what
+this card originally asked for.
+
+Deliberately left unimplemented here. It needs a real decision about cadence and about what happens
+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;.

{boost_skill_cli-1.0.330 → boost_skill_cli-1.0.332}/docs/roadmap.html

@@ -1681,7 +1681,24 @@ than a description of them, and <code>lock_toolchain.py --audit</code> then runs
 normal PR gate once a human opens it.
 
 Either way the freshness gap this item exists to close narrows from "nobody is watching" to "a
-human clicks a button", which is the honest available improvement while the setting stands.</p>
+human clicks a button", which is the honest available improvement while the setting stands.
+
+
+<b>The blocker is gone.</b> This card is gated on the same repository setting as
+<code>demo-cannot-open-its-own-pr</code>, and the API now reports
+<code>can_approve_pull_request_reviews: <b>true</b></code>. Confirmed working rather than merely
+configured: <code>#353</code> was opened by <code>github-actions[bot]</code>.
+
+So the &ldquo;honest available improvement while the setting stands&rdquo; compromise described above
+&mdash; a workflow that only reports drift and waits for a human to click a button &mdash; is no
+longer the ceiling. A scheduled job can now regenerate the lock and open its own PR, which is what
+this card originally asked for.
+
+Deliberately left unimplemented here. It needs a real decision about cadence and about what happens
+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>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m">Impact <b>Med</b></span>
@@ -2591,7 +2608,7 @@ extra ships it.</p>
       </article>
 
       <article class="cap rcard" id="pytest-tmpdir-cve-blocked-by-py39-floor">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Supply chain</span></div>
+        <div class="head"><span class="pill declined">Declined</span><span class="cat">Supply chain</span></div>
         <h3>The <code>pytest</code> tmpdir CVE has no fix at our Python floor</h3>
         <p>CVE-2025-71176 — pytest through 9.0.2 relies on the predictable
 <code>/tmp/pytest-of-{user}</code> path, letting a <b>local</b> user cause a denial of
@@ -2613,7 +2630,22 @@ ephemeral VMs where the local-attacker precondition does not hold. <b>Dismissed
 Revisit when either the 3.9 floor is dropped or a patched 8.x lands. If the floor must stay
 and the alert must clear, the real mitigation is pointing pytest at a private base
 temp dir (<code>--basetemp</code> / <code>PYTEST_DEBUG_TEMPROOT</code>) so the predictable
-path is never used — that fixes the behaviour without satisfying Dependabot's version check.</p>
+path is never used — that fixes the behaviour without satisfying Dependabot's version check.
+
+<b>Declined &mdash; recorded as a decision rather than left to look like pending work.</b> The
+alert is already dismissed upstream as <code>tolerable_risk</code>; leaving the card
+<code>planned</code> made the board advertise work that nobody intends to do and that no code change
+could complete.
+
+The revisit condition was re-checked rather than assumed: this card says revisit &ldquo;when either
+the 3.9 floor is dropped or a patched 8.x lands&rdquo;. PyPI's latest 8.x is still
+<b><code>8.4.2</code></b> &mdash; no <code>8.4.3</code>, no <code>8.5</code> &mdash; and the advisory
+marks every 8.x vulnerable, so there is nothing to move to. The 3.9 floor is a deliberate
+compatibility promise in <code>pyproject.toml</code>, not an oversight.
+
+Reopen this if either condition changes. The residual exposure is unchanged and remains
+contributor-facing only: <code>[project].dependencies</code> is empty, so nobody installing
+<code>boost-skill-cli</code> ever receives pytest.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -3318,7 +3350,7 @@ concrete proof that the original recommendation would have blocked every release
       </article>
 
       <article class="cap rcard" id="demo-cannot-open-its-own-pr">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">CI reporting</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">CI reporting</span></div>
         <h3><code>demo.yml</code> still fails on every push &mdash; and the fix is not in the workflow</h3>
         <p><code>demo-gif-workflow-has-never-succeeded</code> (shipped, PR&nbsp;294) fixed the recorder:
 <code>charmbracelet/vhs-action</code>'s broken ffmpeg installer was replaced with apt plus
@@ -3366,7 +3398,19 @@ permission: since <code>#349</code> switched off Dependabot's version updates fo
 toolchain, the replacement is a scheduled job that regenerates the lock and proposes it &mdash; and
 that job cannot open a pull request either. So this toggle now gates two items rather than one, and
 the second is a supply-chain freshness gap rather than a docs asset. That does not make the
-decision automatic, but it does change what is on each side of it.</p>
+decision automatic, but it does change what is on each side of it.
+
+
+<b>Unblocked, and already working &mdash; the setting was flipped.</b> This card's blocker is
+<code>can_approve_pull_request_reviews: false</code>. The API now reports it as <b><code>true</code></b>,
+and the effect is visible rather than theoretical: <code>demo.yml</code>'s recent runs are green, and
+<b>PR <code>#353</code> was opened by <code>github-actions[bot]</code></b> &mdash; the exact action
+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>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Med</b></span>
@@ -3376,7 +3420,7 @@ decision automatic, but it does change what is on each side of it.</p>
       </article>
 
       <article class="cap rcard" id="merged-loop-branches-are-never-pruned">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Hygiene · DX</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Hygiene · DX</span></div>
         <h3>68 of the repo's 77 branches are merged <code>loop/*</code> branches nobody deletes</h3>
         <p>The repository carries <b>77 branches, 70 of them <code>loop/*</code></b>. Classifying each by the
 state of its pull request: <b>68 have a merged PR</b> and are safe to delete, <b>1</b> has an open
@@ -3409,7 +3453,30 @@ manually.
 Low impact and near-zero risk to fix &mdash; flip <code>delete_branch_on_merge</code> to true and
 the backlog can be pruned by listing merged PR head refs. The reason it is worth doing at all is
 that CLAUDE.md tells every agent to run <code>git worktree list</code> and inspect branch state
-before touching a tree, and 68 stale entries make that check noisier for every concurrent loop.</p>
+before touching a tree, and 68 stale entries make that check noisier for every concurrent loop.
+
+<b>Shipped &mdash; and the premise had gone stale, which is why it was worth re-checking rather than
+assuming.</b> This card's core claim is that <code>delete_branch_on_merge</code> is <code>false</code>.
+It is now <b><code>true</code></b>, and the backlog it describes is gone: against the card's
+<b>77 branches, 70 of them <code>loop/*</code></b>, the repository today carries <b>5 branches, 2
+<code>loop/*</code></b>.
+
+Two stragglers predating the setting change were still present and are now deleted:
+<code>evals-harness</code> (PR <code>#317</code>, merged) and <code>mcp-task-entrance</code>
+(PR <code>#318</code>, merged). Both were classified the way this card insists on &mdash; by
+<b>pull-request state</b>, not commit reachability &mdash; because the squash-merge point above is
+real: <code>compare(main...branch).ahead_by</code> reports every merged branch as permanently ahead,
+so reachability would have reported 0 of them deletable.
+
+Three branches remain and are deliberately <em>not</em> deleted: <code>bot/demo-gif</code> has an
+open PR (<code>#353</code>), and <code>badges</code>, <code>loop/keyless-card-dedupe</code> and
+<code>loop/sbom-in-release-job</code> have <b>no PR on record</b>. A branch with no PR cannot be shown
+to be merged, and deleting it could destroy unmerged work &mdash; so the safe rule is to leave it for
+a human, which is also why no automated pruner is proposed here.
+
+<b>No automation was added.</b> The repository setting does the job going forward; a workflow that
+deleted branches on a schedule would add a way to lose work in exchange for tidying a list that is
+now five entries long.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Low</b></span>
@@ -4454,7 +4521,7 @@ three states: a <b>failing</b> actionlint now fails <code>make</code> (exit 2) i
       </article>
 
       <article class="cap rcard" id="mcp-check-skills-before-starting-a-task">
-        <div class="head"><span class="pill inflight">In flight</span><span class="cat">Interop · Adoption</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Interop · Adoption</span></div>
         <h3>MCP — check for a skill when a task starts, not only when authoring one</h3>
         <p><a href="#mcp-search-before-reinventing">The previous pass</a> gave the MCP server
 <code>initialize</code> <code>instructions</code> and intent-framed tool descriptions, but
@@ -4470,7 +4537,20 @@ duplicate install" to "leverage a capability you already have" — it is the fre
 check. A closing proportion note bounds it, because an unbounded <em>always check first</em>
 turns every trivial turn into a tool call and an agent that learns to ignore the guidance
 ignores all of it. Both triggers and the bound are pinned by tests, so dropping either
-regresses.</p>
+regresses.
+
+<b>Shipped &mdash; the claim was stale, not the work.</b> PR <code>#318</code> merged and its branch
+is gone, but this item sat at <code>inflight</code> under that branch name, so the board advertised
+live work as taken. Verified against the code rather than the PR state alone:
+<code>mcp.INSTRUCTIONS</code> leads with using an installed skill, names <code>boost_list</code> for
+what is usable right now, and carries the proportion bound this card asks for &mdash; &ldquo;Skip it
+for a question, a one-line edit, or a command you were just handed.&rdquo; The trigger is pinned by
+<code>test_instructions_lead_with_using_a_skill_not_authoring_one</code>.
+
+One note for anyone reading both cards: <code>mcp-one-benefit-nameable-task</code> (<code>#355</code>,
+later) <em>superseded</em> this card's &ldquo;two declared triggers&rdquo; framing by demoting
+authoring to a clause on <code>boost_search</code>, on the grounds that it was the rarer moment
+crowding out the common one. The task-start trigger this card argued for is what survived.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -4534,7 +4614,7 @@ open: <code>zizmor</code> and <code>gitleaks</code> run only in CI and have no M
       </article>
 
       <article class="cap rcard" id="mcp-one-benefit-nameable-task">
-        <div class="head"><span class="pill inflight">In flight</span><span class="cat">Interop · Adoption</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Interop · Adoption</span></div>
         <h3>MCP — one benefit, one observable trigger (and stop routing through boost_info)</h3>
         <p>Gemini CLI used the boost MCP server only when asked by hand, never on its own.
 Two causes, and neither was fixed by writing more instructions.
@@ -4564,7 +4644,15 @@ already returns each hit's description, the only field that changes an install d
 so the hop bought a round-trip and a decision point and nothing else. It stays registered
 for looking up a name from elsewhere, and its description now says so. All of it is
 pinned by tests, including negative assertions so authoring and the info hop cannot
-creep back.</p>
+creep back.
+
+<b>Shipped &mdash; the claim was stale, not the work.</b> PR <code>#355</code> merged and its branch
+is gone, yet this item still read as owned. Every element is verifiable in
+<code>mcp.INSTRUCTIONS</code> today: the stated cost (&ldquo;read-only, take about a second, and
+install nothing&rdquo;), the miss protocol (&ldquo;Finding nothing is a good outcome, not a wasted
+call&rdquo;), &ldquo;The task stays yours&rdquo;, and <code>boost_info</code> absent from the
+advertised flow &mdash; which <code>test_instructions_route_search_straight_to_install</code> pins
+with a negative assertion so the hop cannot creep back.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m hi">Impact <b>High</b></span>
@@ -5769,7 +5857,7 @@ same-repo PRs and red CI.</p>
       </article>
 
       <article class="cap rcard" id="code-scanning-rule-can-be-restored">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Release safety</span></div>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Release safety</span></div>
         <h3>The <code>code_scanning</code> ruleset rule can go back on &mdash; but only scoped to CodeQL</h3>
         <p>Repairing the <code>main</code> ruleset dropped its <code>code_scanning</code> rule in favour of
 <code>codeql-analyze</code> as a required status check (see
@@ -5802,7 +5890,23 @@ path filters and runs on <code>push</code>, <code>pull_request</code> and
 <code>merge_group</code>, so it always reports and cannot produce the never-reports deadlock this
 repo has hit twice. And it catches something the status check does not &mdash;
 <code>codeql-analyze</code> passes when the <em>job</em> succeeds, including when it succeeds
-having found error-severity alerts.</p>
+having found error-severity alerts.
+
+<b>Done &mdash; the rule is back, and scoped exactly as this card prescribed.</b> Read from the live
+<code>main</code> ruleset (id <code>19130332</code>): it carries a <code>code_scanning</code> rule
+whose <code>code_scanning_tools</code> list is <b><code>CodeQL</code> alone</b>, at
+<code>security_alerts_threshold: high_or_higher</code> and <code>alerts_threshold: errors</code>.
+Scorecard is not in the list, which is the single decision this card exists to get right.
+
+The safety precondition still holds and was re-checked rather than assumed: <b>CodeQL has 0 open
+alerts</b>, while Scorecard has <b>4 open</b> (down from the 7 recorded above), every one still a
+posture metric that must not be dismissed. Had Scorecard been added to that tool list, those four
+would block every merge in the repository immediately &mdash; the failure mode this card correctly
+identifies as the reason the work looked blocked.
+
+No change was needed. Recording it as shipped so the board stops advertising work that is already
+in place, and so the tool-list constraint stays written down: anyone re-editing this rule through the
+GitHub UI will be offered Scorecard right next to CodeQL in the picker.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Med</b></span>