boost-skill-cli 1.0.334__tar.gz → 1.0.336__tar.gz

{boost_skill_cli-1.0.334/boost_skill_cli.egg-info → boost_skill_cli-1.0.336}/PKG-INFO

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

{boost_skill_cli-1.0.334 → boost_skill_cli-1.0.336}/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.334'
-__version_tuple__ = version_tuple = (1, 0, 334)
+__version__ = version = '1.0.336'
+__version_tuple__ = version_tuple = (1, 0, 336)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.334 → boost_skill_cli-1.0.336/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.334 → boost_skill_cli-1.0.336}/docs/roadmap/items/a11y-sweep-flakes-on-color-contrast.md

@@ -88,3 +88,34 @@ rather than twenty plausible-looking contrast violations against colours that do
 That guard matters more than the flake. Without it the sweep produces confident, specific,
 <em>entirely wrong</em> findings &mdash; which is what sent me to check a token that had been correct
 for months.
+
+<b>Reopened, then actually solved. Both of my earlier diagnoses were wrong, and the card records
+them rather than quietly overwriting.</b>
+
+The stylesheet-load theory in <code>#384</code> predicted that if the flake recurred the sweep would
+report <code>page is unstyled</code>. It recurred on <code>#386</code> and reported <b>10 contrast
+violations on a fully styled page</b> &mdash; so that prediction failed, exactly as the card invited.
+
+What broke it open was a <em>third</em> phantom colour. Across three runs axe reported
+<code>#505467</code>, <code>#656a81</code> and <code>#363948</code>, none of which exist anywhere in
+this repository. A fixed browser fallback cannot drift. Measured against the real token
+<code>#767c96</code>, those three sit at <b>44%, 72% and 20% of its luminance</b> &mdash; the
+signature of one colour composited at varying opacity, not of three different colours.
+
+<b>The cause is <code>.js .reveal</code>: <code>opacity: 0</code> transitioning to <code>1</code> over
+600&nbsp;ms.</b> axe computes contrast from the composited pixel, so running mid-transition grades a
+half-faded element. The failing nodes are <code>.count</code> spans inside
+<code>&lt;section class="block reveal"&gt;</code>. My earlier &ldquo;no <code>.reveal</code> rule on
+this page&rdquo; check was simply wrong: I grepped the <em>page</em>, and the rule lives in the shared
+<code>style/boost.css</code>.
+
+<b>The fix is one line, and the stylesheet was already prepared for it.</b>
+<code>boost.css</code> carries a <code>prefers-reduced-motion: reduce</code> block forcing
+<code>opacity: 1 !important</code> on <code>.reveal</code>; the sweep never asked for that media
+feature. It now calls <code>emulateMediaFeatures</code> before navigating. That is better than
+waiting out the animation, because it audits the page as a motion-sensitive user actually receives
+it &mdash; a settle delay would have papered over a timing race while testing a state no user is
+guaranteed to see.
+
+The <code>#385</code> guard stays: it is orthogonal, it caught a real mis-assumption about
+<code>commands.html</code> on its first run, and an unstyled page still deserves to fail loudly.

{boost_skill_cli-1.0.334 → boost_skill_cli-1.0.336}/docs/roadmap.html

@@ -1989,7 +1989,38 @@ rather than twenty plausible-looking contrast violations against colours that do
 
 That guard matters more than the flake. Without it the sweep produces confident, specific,
 <em>entirely wrong</em> findings &mdash; which is what sent me to check a token that had been correct
-for months.</p>
+for months.
+
+<b>Reopened, then actually solved. Both of my earlier diagnoses were wrong, and the card records
+them rather than quietly overwriting.</b>
+
+The stylesheet-load theory in <code>#384</code> predicted that if the flake recurred the sweep would
+report <code>page is unstyled</code>. It recurred on <code>#386</code> and reported <b>10 contrast
+violations on a fully styled page</b> &mdash; so that prediction failed, exactly as the card invited.
+
+What broke it open was a <em>third</em> phantom colour. Across three runs axe reported
+<code>#505467</code>, <code>#656a81</code> and <code>#363948</code>, none of which exist anywhere in
+this repository. A fixed browser fallback cannot drift. Measured against the real token
+<code>#767c96</code>, those three sit at <b>44%, 72% and 20% of its luminance</b> &mdash; the
+signature of one colour composited at varying opacity, not of three different colours.
+
+<b>The cause is <code>.js .reveal</code>: <code>opacity: 0</code> transitioning to <code>1</code> over
+600&nbsp;ms.</b> axe computes contrast from the composited pixel, so running mid-transition grades a
+half-faded element. The failing nodes are <code>.count</code> spans inside
+<code>&lt;section class="block reveal"&gt;</code>. My earlier &ldquo;no <code>.reveal</code> rule on
+this page&rdquo; check was simply wrong: I grepped the <em>page</em>, and the rule lives in the shared
+<code>style/boost.css</code>.
+
+<b>The fix is one line, and the stylesheet was already prepared for it.</b>
+<code>boost.css</code> carries a <code>prefers-reduced-motion: reduce</code> block forcing
+<code>opacity: 1 !important</code> on <code>.reveal</code>; the sweep never asked for that media
+feature. It now calls <code>emulateMediaFeatures</code> before navigating. That is better than
+waiting out the animation, because it audits the page as a motion-sensitive user actually receives
+it &mdash; a settle delay would have papered over a timing race while testing a state no user is
+guaranteed to see.
+
+The <code>#385</code> guard stays: it is orthogonal, it caught a real mis-assumption about
+<code>commands.html</code> on its first run, and an unstyled page still deserves to fail loudly.</p>
         <div class="meta">
           <span class="m">Complexity <b>S</b></span>
           <span class="m">Impact <b>Med</b></span>

{boost_skill_cli-1.0.334 → boost_skill_cli-1.0.336}/tests/visual/a11y_check.mjs

@@ -73,7 +73,52 @@ for (const rel of PAGES) {
   }
   const page = await browser.newPage();
   await page.setViewport({ width: 1280, height: 900 });
+  // Emulate prefers-reduced-motion BEFORE navigating. `.js .reveal` fades in
+  // over 600ms (opacity 0 -> 1), and axe computes contrast from the COMPOSITED
+  // colour — so running mid-transition reports --text-3 (#767c96, a genuine
+  // 4.85:1) as whatever partial-opacity blend it caught: #363948, #505467 and
+  // #656a81 were all observed, at 20%, 44% and 72% of the token's luminance.
+  // None of those exist anywhere in the repo, which is what made the failures
+  // look like a phantom.
+  //
+  // boost.css already handles this: its `prefers-reduced-motion: reduce` block
+  // forces `opacity: 1 !important` on .reveal. The sweep simply never asked for
+  // it. Emulating the feature is also more honest than waiting out the
+  // animation — it audits the page as a motion-sensitive user receives it.
+  await page.emulateMediaFeatures([
+    { name: "prefers-reduced-motion", value: "reduce" },
+  ]);
   await page.goto("file://" + file, { waitUntil: "load" });
+
+  // Guard: prove the page is actually styled before trusting a contrast result.
+  // Most pages link ../style/boost.css RELATIVELY over file://, which only
+  // works because of --allow-file-access-from-files, and that flag has
+  // intermittently not taken effect on the runner. Colours then fall back to
+  // browser defaults and axe reports a dozen confident, specific, entirely
+  // fictional violations against values that appear nowhere in this repo
+  // (#505467, #656a81 — the real --text-3 is #767c96 at 4.85:1, comfortably AA).
+  //
+  // Probe --bg, NOT --text-3: docs/commands.html is generated self-contained
+  // with its tokens inline and defines no --text-3 at all, so keying on that
+  // token failed a page that was perfectly styled. --bg is defined by both the
+  // shared sheet and every inline :root block, so it detects an unstyled page
+  // without assuming where the styling came from.
+  //
+  // Failing here is the whole point: "not styled" is one line a maintainer can
+  // act on, where the alternative sends them auditing a colour that has been
+  // correct for months.
+  const styled = await page.evaluate(() =>
+    getComputedStyle(document.documentElement)
+      .getPropertyValue("--bg").trim());
+  if (!styled) {
+    console.error(`FAIL ${rel} — page is unstyled (--bg unresolved); `
+      + `every contrast result here would be meaningless, so it is reported `
+      + `as a load failure rather than as violations`);
+    violatingNodes++;
+    await page.close();
+    continue;
+  }
+
   await page.evaluate(axeSource);
   const result = await page.evaluate(
     async (tags) => await window.axe.run(document, { runOnly: { type: "tag", values: tags } }),