boost-skill-cli 1.0.345__tar.gz → 1.0.347__tar.gz

{boost_skill_cli-1.0.345 → boost_skill_cli-1.0.347}/PKG-INFO

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

{boost_skill_cli-1.0.345 → boost_skill_cli-1.0.347}/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.345'
-__version_tuple__ = version_tuple = (1, 0, 345)
+__version__ = version = '1.0.347'
+__version_tuple__ = version_tuple = (1, 0, 347)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.345 → boost_skill_cli-1.0.347}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.0.345 → boost_skill_cli-1.0.347}/boost_skill_cli.egg-info/SOURCES.txt

@@ -192,6 +192,7 @@ docs/roadmap/items/code-scanning-rule-can-be-restored.md
 docs/roadmap/items/codeql-job-rename-stranded-merge-protection.md
 docs/roadmap/items/command-carousel-page.md
 docs/roadmap/items/command-reference-docs-site.md
+docs/roadmap/items/completions-complete-only-command-names.md
 docs/roadmap/items/complexity-and-dead-code-radar-xenon-vulture.md
 docs/roadmap/items/consolidate-skill-staleness-drift-logic-into-cor.md
 docs/roadmap/items/coverage-dashboard-codecov-free-for-oss.md

boost_skill_cli-1.0.347/docs/roadmap/items/completions-complete-only-command-names.md

@@ -0,0 +1,64 @@
+---
+id: completions-complete-only-command-names
+board: code
+section: dx
+status: planned
+category: CLI · DX
+complexity: M
+impact: High
+wow: 4
+note: 79 command names complete; 82 flags and every argument do not
+order: 79
+owner:
+pr:
+title: <code>boost completions</code> completes command names and nothing else
+---
+<b><code>boost install &lt;TAB&gt;</code> should offer skill names. It does not, and what it offers
+instead is different in each shell.</b> boost is a package manager, so completing an installable
+name is the single highest-value completion it could ship &mdash; and it is the one that is wrong in
+the most confusing way.
+
+<b>Measured against the generated scripts</b> (79 commands, <code>docs/commands.html</code> as the
+flag inventory):
+
+all three shells complete <b>79 of 79</b> command names and <b>0</b> flags, and for
+<code>boost install &lt;TAB&gt;</code> <code>bash</code> re-offers the 79 command names,
+<code>zsh</code> offers <b>local filenames</b>, and <code>fish</code> offers nothing.
+
+<b>The command-name half genuinely works</b> &mdash; all three emit exactly the 79 names in
+<code>cli.COMMANDS</code>, verified equal as a set, and zsh and fish carry the one-line summaries.
+Nothing below is a regression; it is scope that was never built.
+
+<b>Each shell fails structurally, not by accident.</b> bash emits
+<code>complete -W "&lt;79 names&gt;" boost</code> with no <code>-F</code> function, and a
+<code>-W</code> wordlist is position-independent by definition &mdash; bash offers the same list at
+argument 1 and argument 5, so after <code>boost install</code> it re-offers command names. zsh
+guards on <code>(( CURRENT == 2 ))</code> and falls through to <code>_files</code>, which is why it
+proposes the contents of your working directory where a skill name belongs &mdash; the most
+misleading of the three, because it looks like a real answer. fish registers every completion under
+<code>__fish_use_subcommand</code>, so it has nothing to say past the first word.
+
+<b>The flag surface is entirely absent.</b> <code>docs/commands.html</code> documents <b>82 distinct
+long flags</b>; the completion scripts contain zero. <code>boost search --&lt;TAB&gt;</code>
+completes nothing in all three shells.
+
+<b>The tests pass and prove the wrong thing, which is why this survived.</b> Four tests in
+<code>TestCompletions</code> assert the emitted text &mdash; that the wordlist equals
+<code>COMMANDS</code>, that there are 79 zsh entries, that fish emits 79 lines. Every one is about
+what the generator <em>prints</em>; none is about what a shell would <em>propose</em>. A test suite
+can be green and thorough about the wrong layer.
+
+<b>Suggested shape: one completer in Python, three thin shims.</b> Add a hidden
+<code>boost __complete &lt;words&gt;</code> that takes the current argv and returns candidates, and
+reduce each shell script to a delegation (<code>-F</code> for bash, <code>_boost</code> calling it
+for zsh, a function for fish). That puts the logic in <code>core/</code> where the mutation gate
+reaches it and where it can be unit-tested in Python, instead of triplicating context rules across
+three shell dialects that cannot share a test. It also lets candidates be <em>dynamic</em>:
+installed skills for <code>uninstall</code>, catalog names for <code>install</code> and
+<code>info</code>, tap names for <code>untap</code>, profiles for <code>profile</code>.
+
+<b>Two constraints worth stating before anyone starts.</b> Completion runs on every keystroke-ish
+TAB, so the candidate path must not pay catalog-scan cost &mdash; it needs the cached catalog, and a
+budget (target &lt;100&nbsp;ms) measured rather than assumed. And <code>__complete</code> must never
+fail loudly: a completer that prints a traceback into the user's prompt is worse than one that
+returns nothing, so it should exit 0 with empty output on any error.

boost_skill_cli-1.0.347/docs/roadmap/items/roadmap-page-weight-grows-without-bound.md

@@ -0,0 +1,105 @@
+---
+id: roadmap-page-weight-grows-without-bound
+board: code
+section: docsite
+status: shipped
+category: Docs · Performance
+complexity: M
+impact: High
+wow: 2
+note: it was never the bytes — 705 ms of styleLayout was, and 55.5% of elements now skip it
+order: 76
+owner:
+pr:
+title: <code>roadmap.html</code> grew 36% in one session and nothing bounds it
+---
+The generated board is <b>407.6&nbsp;KB, of which 404.7&nbsp;KB is markup</b> — 189
+<code>&lt;article&gt;</code> cards rendered eagerly into one DOM. Measured across this session's
+merges it went <b>301.6&nbsp;KB &rarr; 409.9&nbsp;KB, a 36% rise</b>, monotonically increasing with
+every card documented.
+
+<b>The mechanism is that shipped work never stops costing.</b> Sizing the sections: <code>shipped</code>
+17.6&nbsp;KB / 16 cards, <code>next</code> 1.1&nbsp;KB / 1, <code>planned</code>
+<b>383.0&nbsp;KB / 172</b> — but 164 of those 172 carry a <code>shipped</code> pill. They are finished
+items grouped under their original section, each still rendering its full body, and those bodies grow
+because closing an item well means recording what was measured and what turned out to be wrong. The
+board is now mostly an archive that every visitor downloads in full.
+
+<b>This is NOT what failed <code>lighthouse</code> on <code>#386</code>, and that is worth stating
+because the correlation is seductive.</b> <code>#388</code> passed the same gate at
+<b>409.9&nbsp;KB</b> — very slightly <em>larger</em> than <code>#386</code>'s 409.8&nbsp;KB, which
+failed. A bigger page scoring better rules out page weight as that failure's cause; it was runner
+variance, exactly as <code>lighthouse.yml</code>'s own comment predicts ("a single sample dips into
+the 80s under runner load, which the median absorbs"). The performance floor is
+<code>minScore 0.85</code> against a normal score of ~99–100, so there is real headroom today.
+
+<b>The case for doing it anyway is the trend, not the current number.</b> At roughly +6&nbsp;KB per
+merged card the page crosses 500&nbsp;KB within a few working sessions, and DOM size is precisely
+what Lighthouse's performance category penalises — so this becomes the cause eventually even though
+it is not the cause now.
+
+<b>Likely levers, cheapest first.</b> Collapse shipped card bodies behind
+<code>&lt;details&gt;</code> so the text ships but does not render — that alone addresses the
+383&nbsp;KB block and keeps every word searchable in the source. Failing that, render shipped items
+as one-line entries linking to their item file, or paginate by section. All three live in
+<code>scripts/build_roadmap.py</code>; none require touching an item file, which matters because the
+item files are the merge-conflict-free part of this design.
+
+<b>Do not raise the Lighthouse floor to fix this.</b> The floor is calibrated and honest; a page that
+outgrows it should be made smaller, not re-graded.
+
+<b>Update &mdash; the prediction above came true, and the card's own headline claim is now false.</b>
+This card argued page weight &ldquo;is <em>not</em> the cause now&rdquo; of any
+<code>lighthouse</code> failure, and that it would become the cause eventually. Eventually arrived on
+<code>#395</code>: <code>docs/roadmap.html</code> scored <b>0.74, 0.77, 0.81</b> against the
+<code>minScore 0.85</code> floor &mdash; <b>all three runs below the floor</b>, not a single sample
+dipping under load. The board was <b>433.7&nbsp;KB / 192 cards</b> at that point, against the
+407.6&nbsp;KB / 189 recorded when this card was filed.
+
+<b>The distinction that matters for whoever picks this up:</b> the earlier <code>#386</code> failure
+really was runner variance &mdash; <code>#388</code> passed at a very slightly <em>larger</em> size,
+which is what ruled weight out then. This one is not the same shape. <code>main</code> passed at
+<b>430.0&nbsp;KB</b> one minute earlier on the same runner class, and <code>#395</code>'s
+<em>best</em> of three runs was below <code>main</code>'s worst. So the honest reading is not
+&ldquo;+3.7&nbsp;KB broke it&rdquo; &mdash; a 0.9% size change cannot move a score that far. It is
+that the page now sits <b>on the cliff</b>, with roughly 0.07 of run-to-run spread straddling the
+floor, so it fails intermittently and will fail more often as cards accrue. Headroom, not the mean,
+is what was spent.
+
+<b>This also raises the cost of documenting work well</b>, which is the uncomfortable part: closing a
+card properly means recording what was measured and what turned out wrong, and every such paragraph
+now pushes a shared gate closer to red. That is an argument for the <code>&lt;details&gt;</code>
+lever rather than for writing less.
+
+<b>Shipped &mdash; and the measurement corrected the card's own framing.</b> This item is titled for
+page <em>weight</em>, and every earlier paragraph reasons about kilobytes. Reading the Lighthouse
+artefact from the failing run shows bytes were never the mechanism. Of 1.6&nbsp;s of main-thread
+work: <code>styleLayout</code> <b>705&nbsp;ms</b>, <code>paintCompositeRender</code>
+<b>393&nbsp;ms</b>, <code>parseHTML</code> 83&nbsp;ms, <code>scriptEvaluation</code>
+<b>20&nbsp;ms</b>. The page was slow because the browser <em>lays out and paints</em> 6,316 elements,
+not because it downloads 440&nbsp;KB and not because of JavaScript.
+
+<b>The weighted losses name the same thing.</b> Reconstructing the 0.74: TBT 0.58 &times; 30%, LCP
+0.69 &times; 25%, FCP 0.47 &times; 10%, SI 0.93 &times; 10%, CLS 1.00 &times; 25% &rarr; 0.7365.
+Worth noting <code>dom-size</code> scored <b>0</b> at 6,316 elements but is <em>unweighted</em> in
+the performance category &mdash; so the obvious-looking number was not the one costing the score,
+which is exactly the trap of optimising against a diagnostic instead of the metric.
+
+<b>The fix is the cheapest lever this card already proposed, for a better reason than it gave.</b>
+<code>build_roadmap.py</code> now wraps a <code>shipped</code> card's body in a closed
+<code>&lt;details&gt;</code> &mdash; <b>188 of 192 cards</b>. A closed <code>&lt;details&gt;</code>
+subtree still parses and still ships, so every word stays greppable and findable by the browser's own
+find-in-page, but it is never laid out or painted: <b>3,764 of 6,781 elements (55.5%)</b> now skip
+both. Anything a reader might act on &mdash; <code>planned</code>, <code>next</code>,
+<code>inflight</code> &mdash; stays expanded.
+
+<b>The page got bigger, and that is the point.</b> 440.3&nbsp;KB &rarr; <b>453.5&nbsp;KB</b>, because
+188 <code>&lt;summary&gt;</code> elements cost ~13&nbsp;KB. Under the original framing that reads as
+a regression; under the measurement it is irrelevant, because transfer was never what breached the
+floor. Had this been fixed by chasing kilobytes, the work would have been aimed at the one number
+the score does not weigh.
+
+<b>Not claimed:</b> a resulting Lighthouse score. It could not be reproduced locally (no Chrome in
+this sandbox), so the element count is the measured claim and CI's own <code>lighthouse</code> job is
+the verdict.
+