boost-skill-cli 1.1.0__tar.gz → 1.1.1__tar.gz

{boost_skill_cli-1.1.0 → boost_skill_cli-1.1.1}/PKG-INFO

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

{boost_skill_cli-1.1.0 → boost_skill_cli-1.1.1}/boost_cli/_version.py

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

{boost_skill_cli-1.1.0 → boost_skill_cli-1.1.1}/boost_skill_cli.egg-info/PKG-INFO

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

{boost_skill_cli-1.1.0 → boost_skill_cli-1.1.1}/boost_skill_cli.egg-info/SOURCES.txt

@@ -399,6 +399,7 @@ docs/roadmap/items/stop-re-serializing-entry-meta-on-every-search.md
 docs/roadmap/items/structured-json-log-output-mode.md
 docs/roadmap/items/supply-chain-posture-openssf-scorecard.md
 docs/roadmap/items/surface-every-docs-page-from-the-guide.md
+docs/roadmap/items/sweep-died-at-launch-not-at-a-page.md
 docs/roadmap/items/sync-could-not-repair-a-gutted-skill.md
 docs/roadmap/items/sync-deletes-unowned-broken-symlinks.md
 docs/roadmap/items/sync-relinks-into-every-agent-ignoring-scope.md
@@ -698,6 +699,7 @@ tests/unit/test_typosquat.py
 tests/unit/test_updatediff.py
 tests/unit/test_util.py
 tests/unit/test_version.py
+tests/unit/test_visual_harness_flags.py
 tests/unit/test_workflow_concurrency.py
 tests/unit/test_workflow_concurrency_groups.py
 tests/unit/test_workflow_push_has_credentials.py

boost_skill_cli-1.1.1/docs/roadmap/items/sweep-died-at-launch-not-at-a-page.md

@@ -0,0 +1,64 @@
+---
+id: sweep-died-at-launch-not-at-a-page
+board: code
+section: pipeline
+status: inflight
+category: CI · Bug
+complexity: S
+impact: High
+wow: 4
+note: a comment in the sibling file predicted this exact failure
+order: 114
+owner: fix/visual-sweep-single-process
+pr:
+title: The <code>sweep</code> gate died at browser launch, not at a page
+---
+Every <code>sweep</code> run failed from 2026-08-15 onward — on <code>main</code>
+and on every branch — and the failure was not a visual regression at all. Chrome
+died during the CDP startup handshake, before a single page loaded:
+
+<code>TargetCloseError: Protocol error (Target.setAutoAttach): Target closed</code>
+out of <code>ChromeLauncher.launch</code>.
+
+<b>The trigger was the environment, and the evidence is an A/B on identical
+trees.</b> <code>#515</code>'s own PR run passed on 2026-08-13 at 17:22; the
+byte-identical squash-merge failed on 2026-08-15 at 22:10. Same content, opposite
+result, two days apart — the <code>ubuntu-latest</code> runner image bumped
+Chrome underneath it. Nothing in the repo changed;
+<code>visual_check.mjs</code> had carried the same flags since <code>#209</code>.
+
+<b>The sibling file predicted it, in a comment, by name.</b>
+<code>a11y_check.mjs</code> was fixed earlier to scope <code>--single-process</code>
+to the <code>chrome-headless-shell</code> binary, and its comment recorded why the
+other half of the directory was still exposed: <em>"visual_check.mjs already
+passes the flag … <code>--single-process</code> is a debug-only flag there whose
+interaction with new headless nothing in this repo exercises."</em> That is
+exactly the interaction that broke.
+
+<b>Two candidate causes, both addressed, because the CI path cannot be
+reproduced locally.</b> <code>--single-process</code> is debug-only and
+unsupported against full Chrome; and <code>headless: "shell"</code> asks for the
+old headless mode, which Chrome removed from the main binary and now ships only
+as the separate <code>chrome-headless-shell</code> executable. Both are now
+conditioned on the same predicate the a11y harness uses, so against
+<code>/usr/bin/google-chrome</code> the sweep launches in new headless with
+neither flag — the shape <code>a11y_check.mjs</code> has been driving on this
+runner all along. Keyed on the <em>binary</em> rather than on
+<code>process.platform</code>: a macOS run pointed at full Chrome must not
+inherit a flag meant for the shell.
+
+<b>What was verified, and what was not.</b> The harness runs end to end and
+passes <b>10 pages × 5 widths clean</b> against a downloaded
+<code>chrome-headless-shell</code> 152 — which also proves the docs pages
+themselves were never the problem. The flag selection was evaluated directly for
+four binary paths. The <em>CI</em> path is not locally reproducible and this card
+says so rather than implying otherwise: full Chrome cannot start under this macOS
+sandbox at all, aborting with <code>The browser is already running for
+&lt;fresh profile dir&gt;</code> from ProcessSingleton — a different error from
+CI's, so it is interference, not a reproduction. CI is the verifier.
+
+<b>The ratchet.</b> <code>tests/unit/test_visual_harness_flags.py</code> fails
+the build if either harness hands a sandbox-only flag to a full Chrome, and if
+the two stop agreeing on the predicate. The bug here was not the flag — it was
+that one file was fixed and the other was not, and the only thing recording that
+was a comment. A comment cannot fail a build.

{boost_skill_cli-1.1.0 → boost_skill_cli-1.1.1}/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>250</b><span>Loop finds</span></div>
+      <div class="stat"><b>251</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -6507,6 +6507,66 @@ the push.</p></details>
           <span class="m">a comment four lines long un-silenced a reviewed finding, and no local gate could see it</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="sweep-died-at-launch-not-at-a-page">
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">CI · Bug</span></div>
+        <h3>The <code>sweep</code> gate died at browser launch, not at a page</h3>
+        <p>Every <code>sweep</code> run failed from 2026-08-15 onward — on <code>main</code>
+and on every branch — and the failure was not a visual regression at all. Chrome
+died during the CDP startup handshake, before a single page loaded:
+
+<code>TargetCloseError: Protocol error (Target.setAutoAttach): Target closed</code>
+out of <code>ChromeLauncher.launch</code>.
+
+<b>The trigger was the environment, and the evidence is an A/B on identical
+trees.</b> <code>#515</code>'s own PR run passed on 2026-08-13 at 17:22; the
+byte-identical squash-merge failed on 2026-08-15 at 22:10. Same content, opposite
+result, two days apart — the <code>ubuntu-latest</code> runner image bumped
+Chrome underneath it. Nothing in the repo changed;
+<code>visual_check.mjs</code> had carried the same flags since <code>#209</code>.
+
+<b>The sibling file predicted it, in a comment, by name.</b>
+<code>a11y_check.mjs</code> was fixed earlier to scope <code>--single-process</code>
+to the <code>chrome-headless-shell</code> binary, and its comment recorded why the
+other half of the directory was still exposed: <em>"visual_check.mjs already
+passes the flag … <code>--single-process</code> is a debug-only flag there whose
+interaction with new headless nothing in this repo exercises."</em> That is
+exactly the interaction that broke.
+
+<b>Two candidate causes, both addressed, because the CI path cannot be
+reproduced locally.</b> <code>--single-process</code> is debug-only and
+unsupported against full Chrome; and <code>headless: "shell"</code> asks for the
+old headless mode, which Chrome removed from the main binary and now ships only
+as the separate <code>chrome-headless-shell</code> executable. Both are now
+conditioned on the same predicate the a11y harness uses, so against
+<code>/usr/bin/google-chrome</code> the sweep launches in new headless with
+neither flag — the shape <code>a11y_check.mjs</code> has been driving on this
+runner all along. Keyed on the <em>binary</em> rather than on
+<code>process.platform</code>: a macOS run pointed at full Chrome must not
+inherit a flag meant for the shell.
+
+<b>What was verified, and what was not.</b> The harness runs end to end and
+passes <b>10 pages × 5 widths clean</b> against a downloaded
+<code>chrome-headless-shell</code> 152 — which also proves the docs pages
+themselves were never the problem. The flag selection was evaluated directly for
+four binary paths. The <em>CI</em> path is not locally reproducible and this card
+says so rather than implying otherwise: full Chrome cannot start under this macOS
+sandbox at all, aborting with <code>The browser is already running for
+&lt;fresh profile dir&gt;</code> from ProcessSingleton — a different error from
+CI's, so it is interference, not a reproduction. CI is the verifier.
+
+<b>The ratchet.</b> <code>tests/unit/test_visual_harness_flags.py</code> fails
+the build if either harness hands a sandbox-only flag to a full Chrome, and if
+the two stop agreeing on the predicate. The bug here was not the flag — it was
+that one file was fixed and the other was not, and the only thing recording that
+was a comment. A comment cannot fail a build.</p>
+        <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">a comment in the sibling file predicted this exact failure</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

boost_skill_cli-1.1.1/tests/unit/test_visual_harness_flags.py

@@ -0,0 +1,121 @@
+"""Unit tests: the Chrome flags the two headless sweeps launch with.
+
+`tests/visual/` holds two puppeteer harnesses that drive the same binary on the
+same runner — `visual_check.mjs` (render regression) and `a11y_check.mjs`
+(axe-core). They must agree about `--single-process`, and for two days they did
+not.
+
+`--single-process` exists for one reason: `chrome-headless-shell` is the only
+binary that starts under a macOS sandbox denying Mach port rendezvous, and it
+needs the flag to get there. On CI the binary is `/usr/bin/google-chrome`, where
+the flag is debug-only and unsupported. `a11y_check.mjs` was fixed to scope it to
+the shell binary and its comment recorded that `visual_check.mjs` still passed it
+unconditionally — that prediction came true when the runner image bumped Chrome:
+
+    TargetCloseError: Protocol error (Target.setAutoAttach): Target closed
+        at ChromeLauncher.launch (…/ChromeLauncher.js:39:16)
+
+The browser died during the CDP startup handshake, so `sweep` failed before a
+single page loaded — on every branch and on `main`. The tell that it was the
+environment and not the repo: #515's own PR run passed on 2026-08-13 and the
+byte-identical squash-merge failed on 2026-08-15.
+
+These tests are the ratchet. The flag stays available for the sandbox that needs
+it, and neither harness may hand it to a full Chrome again.
+"""
+from __future__ import annotations
+
+import re
+from pathlib import Path
+
+import pytest
+
+ROOT = Path(__file__).resolve().parent.parent.parent
+HARNESSES = {
+    "visual_check.mjs": ROOT / "tests" / "visual" / "visual_check.mjs",
+    "a11y_check.mjs": ROOT / "tests" / "visual" / "a11y_check.mjs",
+}
+
+#: Flags that only ever belong to the sandboxed `chrome-headless-shell` run.
+#: `--in-process-gpu` is here because it is half of the same workaround — it
+#: pairs with `--single-process` and is equally pointless against full Chrome.
+SANDBOX_ONLY_FLAGS = ("--single-process", "--in-process-gpu")
+
+
+def _source(name: str) -> str:
+    path = HARNESSES[name]
+    assert path.is_file(), "%s is missing" % path
+    return path.read_text(encoding="utf-8")
+
+
+def _code_lines(src: str) -> list[str]:
+    """Source lines with `//` comments dropped.
+
+    The flag is *named* in prose in both files — that is the documentation, not
+    an invocation, and asserting over raw text would fail on the comment that
+    explains the rule.
+    """
+    out = []
+    for line in src.splitlines():
+        stripped = line.strip()
+        if stripped.startswith("//"):
+            continue
+        out.append(line.split("//", 1)[0])
+    return out
+
+
+@pytest.mark.parametrize("name", sorted(HARNESSES))
+class TestSandboxFlagsAreConditional:
+    def test_no_sandbox_only_flag_is_passed_unconditionally(self, name):
+        """A bare flag in the args array is what broke CI for two days."""
+        for line in _code_lines(_source(name)):
+            for flag in SANDBOX_ONLY_FLAGS:
+                if flag not in line:
+                    continue
+                assert "?" in line or "&&" in line, (
+                    "%s passes %s unconditionally (%r) — on CI the binary is "
+                    "full Chrome, where it kills the browser at launch"
+                    % (name, flag, line.strip()))
+
+    def test_the_guard_is_keyed_on_the_shell_binary(self, name):
+        """Scoped by *binary*, not by platform: what needs the flag is
+        `chrome-headless-shell`, and a macOS runner using full Chrome must not
+        inherit it."""
+        src = _source(name)
+        if not any(f in src for f in SANDBOX_ONLY_FLAGS):
+            pytest.skip("%s passes no sandbox-only flag" % name)
+        assert re.search(r"/chrome\[-_\]headless\[-_\]shell/\.test\(bin\)", src), (
+            "%s gates the flag on something other than the shell binary — "
+            "`process.platform` is the tempting wrong answer, because a macOS "
+            "run pointed at full Chrome would then inherit it" % name)
+
+    def test_ci_binary_path_is_still_a_candidate(self, name):
+        """The guard is only meaningful while CI really does use full Chrome."""
+        assert "/usr/bin/google-chrome" in _source(name)
+
+
+class TestTheTwoHarnessesAgree:
+    """They drive the same binary on the same runner in the same job."""
+
+    def test_both_use_the_same_predicate(self):
+        preds = {}
+        for name in HARNESSES:
+            src = _source(name)
+            m = re.search(r"=\s*(/chrome.*?/)\.test\(bin\)", src)
+            preds[name] = m.group(1) if m else None
+        assert len(set(preds.values())) == 1, (
+            "the harnesses disagree about which binary needs the flag: %r"
+            % preds)
+        assert all(preds.values()), (
+            "a harness has no shell-binary predicate at all: %r" % preds)
+
+    def test_neither_hands_a_sandbox_flag_to_full_chrome(self):
+        """The end state, stated once over both files."""
+        offenders = [
+            (name, line.strip())
+            for name in HARNESSES
+            for line in _code_lines(_source(name))
+            for flag in SANDBOX_ONLY_FLAGS
+            if flag in line and "?" not in line and "&&" not in line
+        ]
+        assert not offenders, offenders

{boost_skill_cli-1.1.0 → boost_skill_cli-1.1.1}/tests/visual/visual_check.mjs

@@ -47,12 +47,40 @@ if (!bin) {
   process.exit(2);
 }
 
+// `--single-process` (and the `--in-process-gpu` half of the same workaround)
+// exists for exactly one binary: `chrome-headless-shell` is the only thing that
+// starts under a macOS sandbox denying Mach port rendezvous, and it needs the
+// flag to get there — see the matching block in a11y_check.mjs, which scoped it
+// first and recorded that this file still passed it unconditionally.
+//
+// That prediction came true. On CI the binary is /usr/bin/google-chrome, where
+// the flag is debug-only and unsupported; when the runner image bumped Chrome,
+// the browser began dying during the CDP startup handshake and every `sweep`
+// run failed before a page loaded:
+//
+//   TargetCloseError: Protocol error (Target.setAutoAttach): Target closed
+//       at ChromeLauncher.launch (…/ChromeLauncher.js:39:16)
+//
+// The tell that it was the environment and not the repo: #515's own PR run
+// passed on 2026-08-13 and the byte-identical squash-merge failed on 08-15.
+//
+// `headless` moves with it. "shell" is the old headless mode, which is what the
+// separate chrome-headless-shell binary provides; against full Chrome we take
+// puppeteer's default (new headless), which is the mode a11y_check.mjs has been
+// driving on this runner all along. Keyed on the binary rather than on
+// `process.platform`, so a macOS run pointed at full Chrome does not inherit a
+// flag meant for the shell.
+const needsSingleProcess = /chrome[-_]headless[-_]shell/.test(bin);
+
 const browser = await launch({
   executablePath: bin,
   pipe: true,                       // no listening socket (sandbox-safe)
-  headless: "shell",
-  args: ["--no-sandbox", "--disable-gpu", "--in-process-gpu", "--single-process",
-         "--disable-dev-shm-usage", "--hide-scrollbars"],
+  ...(needsSingleProcess ? { headless: "shell" } : {}),
+  args: [
+    "--no-sandbox", "--disable-gpu", "--disable-dev-shm-usage",
+    "--hide-scrollbars",
+    ...(needsSingleProcess ? ["--in-process-gpu", "--single-process"] : []),
+  ],
 });
 
 // Containers allowed to hide content behind their own horizontal scroll.