boost-skill-cli 1.2.34__tar.gz → 1.2.35__tar.gz

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.35}/CONTRIBUTING.md

@@ -257,6 +257,17 @@ branch ruleset (**Settings → Rules → Rulesets**):
   gate before it can merge, so an incompatible pair can't both land — the second
   PR must include the first and re-run CI.
 
+> **Set it in the ruleset, and verify it from the API.** This repository asks
+> for that rule in two places, and for a while neither one enforced it. Classic
+> branch protection had `strict: true` *and* `enforce_admins: false`, so it
+> skipped the only account that merges; the active ruleset — no bypass actors,
+> so it does apply — had `strict_required_status_checks_policy: false`. Two
+> mechanisms, and the binding one had the safety off. Two PRs then merged into
+> a red `main`, which stopped the release guard arming and left two merged PRs
+> unreleased. Check the real state with
+> `gh api repos/jonnyeclectic/boost/rulesets/<id>`, never the settings page,
+> and note that the `branch-current` required check now backstops it.
+>
 > Check names must be **unique across workflows** — GitHub matches a required
 > check by name alone. Three names collided before this was written (`lint` in
 > ci/markdownlint/theme-lint, `audit` in lighthouse/pip-audit, `analyze` in

{boost_skill_cli-1.2.34/boost_skill_cli.egg-info → boost_skill_cli-1.2.35}/PKG-INFO

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

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.35}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.2.34'
-__version_tuple__ = version_tuple = (1, 2, 34)
+__version__ = version = '1.2.35'
+__version_tuple__ = version_tuple = (1, 2, 35)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.35/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.35}/boost_skill_cli.egg-info/SOURCES.txt

@@ -213,6 +213,7 @@ docs/roadmap/items/boost-first-carried-the-losing-trigger.md
 docs/roadmap/items/boost-first-rule.md
 docs/roadmap/items/boost-langchain-publishing.md
 docs/roadmap/items/boost-run-live-agents.md
+docs/roadmap/items/branch-current-gate.md
 docs/roadmap/items/bring-commands-under-mutation-testing.md
 docs/roadmap/items/broken-link-and-anchor-checking-lychee.md
 docs/roadmap/items/browse-could-not-search-two-words.md
@@ -508,6 +509,7 @@ scripts/build_registries.py
 scripts/build_roadmap.py
 scripts/build_scale_corpus.py
 scripts/check_anchors.py
+scripts/check_branch_current.py
 scripts/check_dco.py
 scripts/check_licenses.py
 scripts/check_reproducible.py
@@ -627,6 +629,7 @@ tests/unit/test_ai.py
 tests/unit/test_bmad_core.py
 tests/unit/test_boost_first_offer.py
 tests/unit/test_bootstrap.py
+tests/unit/test_branch_current.py
 tests/unit/test_browse.py
 tests/unit/test_builtin.py
 tests/unit/test_capabilities.py

boost_skill_cli-1.2.35/docs/roadmap/items/branch-current-gate.md

@@ -0,0 +1,39 @@
+---
+id: branch-current-gate
+board: code
+section: health
+status: inflight
+category: CI · Release safety
+complexity: S
+impact: High
+wow: 4
+note: two protection mechanisms disagreed; the binding one had the safety off
+order: 10
+owner: loop/generated-freshness
+pr:
+title: main went red because "require branches up to date" was never actually on
+---
+Two pull requests, each green against the <code>main</code> it was tested on, merged into a
+combination that turned <code>main</code> red. Their source files did not conflict. The
+<b>generated</b> <code>docs/roadmap.html</code> did — and a squash merge takes one side of a
+generated file <b>without ever reporting a conflict</b>. The board's "Loop finds" counter was
+correct on both branches and wrong for their union.
+<b>Seventeen jobs failed on one line.</b> Ten test legs, the lint job and all six mutation
+shards — the shards because the unit suite runs inside <code>mutants/</code>, where
+<code>test_roadmap_fresh</code> fails baseline <i>collection</i>, so a stale generated file
+reads as "the mutation gate could not start". And because <code>ci</code> was red on
+<code>main</code>, the release workflow's guard never armed: two merged pull requests, one of
+them the reproducible-build pipeline, sat on <code>main</code> with no tag.
+<b>The root cause was a setting, and the trap was that it looked set.</b> The repository asks
+GitHub to require branches be up to date <b>twice</b>. Classic branch protection has
+<code>strict: true</code> — and <code>enforce_admins: false</code>, so it does not apply to the
+one account that merges. The active ruleset, which has no bypass actors and therefore does
+apply, had <code>strict_required_status_checks_policy: false</code>. Two mechanisms, and the
+binding one had the safety off. They also disagreed on how many checks are required: 14, 20,
+and 21 in <code>required-checks.txt</code>.
+<b>Fixed both ways.</b> The ruleset now enforces up-to-date merges, verified by reading it back
+from the API rather than trusting the settings page. And <code>branch-current</code> is now a
+required check, because that setting is invisible config that drifted once and can drift again
+— a required check is in the diff, in <code>required-checks.txt</code>, and shows up in review.
+Within minutes of the fix, GitHub moved two open pull requests to <code>behind</code> and
+refused them; an hour earlier both would have merged and broken <code>main</code> a second time.

{boost_skill_cli-1.2.34 → boost_skill_cli-1.2.35}/docs/roadmap.html

@@ -133,7 +133,7 @@
       <div class="stat"><b>17</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>278</b><span>Loop finds</span></div>
+      <div class="stat"><b>279</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -5015,6 +5015,41 @@ re-embeds every vector already paid for.</p>
         </div>
       </article>
 
+      <article class="cap rcard" id="branch-current-gate">
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">CI · Release safety</span></div>
+        <h3>main went red because "require branches up to date" was never actually on</h3>
+        <p>Two pull requests, each green against the <code>main</code> it was tested on, merged into a
+combination that turned <code>main</code> red. Their source files did not conflict. The
+<b>generated</b> <code>docs/roadmap.html</code> did — and a squash merge takes one side of a
+generated file <b>without ever reporting a conflict</b>. The board's "Loop finds" counter was
+correct on both branches and wrong for their union.
+<b>Seventeen jobs failed on one line.</b> Ten test legs, the lint job and all six mutation
+shards — the shards because the unit suite runs inside <code>mutants/</code>, where
+<code>test_roadmap_fresh</code> fails baseline <i>collection</i>, so a stale generated file
+reads as "the mutation gate could not start". And because <code>ci</code> was red on
+<code>main</code>, the release workflow's guard never armed: two merged pull requests, one of
+them the reproducible-build pipeline, sat on <code>main</code> with no tag.
+<b>The root cause was a setting, and the trap was that it looked set.</b> The repository asks
+GitHub to require branches be up to date <b>twice</b>. Classic branch protection has
+<code>strict: true</code> — and <code>enforce_admins: false</code>, so it does not apply to the
+one account that merges. The active ruleset, which has no bypass actors and therefore does
+apply, had <code>strict_required_status_checks_policy: false</code>. Two mechanisms, and the
+binding one had the safety off. They also disagreed on how many checks are required: 14, 20,
+and 21 in <code>required-checks.txt</code>.
+<b>Fixed both ways.</b> The ruleset now enforces up-to-date merges, verified by reading it back
+from the API rather than trusting the settings page. And <code>branch-current</code> is now a
+required check, because that setting is invisible config that drifted once and can drift again
+— a required check is in the diff, in <code>required-checks.txt</code>, and shows up in review.
+Within minutes of the fix, GitHub moved two open pull requests to <code>behind</code> and
+refused them; an hour earlier both would have merged and broken <code>main</code> a second time.</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">two protection mechanisms disagreed; the binding one had the safety off</span>
+        </div>
+      </article>
+
       <article class="cap rcard" id="log-timestamps-mislabeled-utc">
         <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Observability · Diagnostics</span></div>
         <h3>Log timestamps are local time mislabeled <code>Z</code></h3>

boost_skill_cli-1.2.35/scripts/check_branch_current.py

@@ -0,0 +1,94 @@
+#!/usr/bin/env python3
+# Copyright the boost contributors.
+# SPDX-License-Identifier: GPL-3.0-only
+"""Fail a pull request that does not contain the base branch's tip.
+
+Every merge to `main` cuts a PyPI release, and two pull requests that are each
+green in isolation can still land a broken *combination*. That is not
+hypothetical here: on 2026-08-29 two of them each added a roadmap item and each
+regenerated `docs/roadmap.html`. The item files merged cleanly — that is what
+the file-per-item design is for — but the generated board is one shared file,
+and a squash merge takes one side of it without reporting a conflict. `main`
+went red on a counter that was correct on both branches and wrong for their
+union, and because `ci` was red the release workflow's guard never armed, so
+two merged pull requests sat unreleased.
+
+GitHub can enforce this natively and the repository asks it to twice, which is
+the trap. Classic branch protection sets `strict: true` but also
+`enforce_admins: false`, so it does not apply to the account that does the
+merging; the active ruleset, which has no bypass actors and therefore does
+apply, sets `strict_required_status_checks_policy: false`. Two mechanisms, and
+the binding one had the safety off. A required *check* is enforced by the
+ruleset either way, which is why this lives in the repository instead of in a
+settings page nobody can diff.
+
+Usage (CI passes the base explicitly; locally it defaults to origin/main)::
+
+    python3 scripts/check_branch_current.py
+    python3 scripts/check_branch_current.py --base origin/main
+"""
+from __future__ import annotations
+
+import argparse
+import subprocess
+import sys
+
+
+def problem(base_sha: str, *, contains_base: bool) -> str | None:
+    """The message to print, or None when the branch is current.
+
+    Split from the git plumbing so the verdict is a pure function of the one
+    thing that decides it: whether this branch already contains the base tip.
+    """
+    if contains_base:
+        return None
+    return (
+        "this branch does not contain %s, the current tip of the base branch.\n"
+        "  Two branches that are each green can still merge into a broken\n"
+        "  combination — a generated file is the usual way, since a squash\n"
+        "  merge takes one side of it without reporting a conflict.\n"
+        "  Fix: git fetch origin main && git rebase origin/main\n"
+        "  then re-run `make generate` and commit any drift."
+    ) % base_sha
+
+
+def _git(*args: str) -> str:
+    return subprocess.run(["git", *args], check=True,
+                          capture_output=True, text=True).stdout.strip()
+
+
+def contains(base: str) -> tuple[str, bool]:
+    """(base sha, whether HEAD already contains it)."""
+    base_sha = _git("rev-parse", base)
+    result = subprocess.run(["git", "merge-base", "--is-ancestor", base_sha, "HEAD"],
+                            capture_output=True, text=True)
+    return base_sha, result.returncode == 0
+
+
+def main(argv: list[str]) -> int:
+    parser = argparse.ArgumentParser(description=__doc__)
+    parser.add_argument("--base", default="origin/main",
+                        help="base ref the branch must contain (default: origin/main)")
+    args = parser.parse_args(argv)
+
+    try:
+        base_sha, ok = contains(args.base)
+    except subprocess.CalledProcessError:
+        # No such ref — a shallow clone or a fork without the base fetched.
+        # Report it rather than passing silently: a check that cannot look is
+        # not a check that passed.
+        print("check-branch-current: cannot resolve %s — fetch it first" % args.base,
+              file=sys.stderr)
+        return 2
+
+    found = problem(base_sha, contains_base=ok)
+    if found is None:
+        print("check-branch-current: OK — branch contains %s (%s)"
+              % (args.base, base_sha[:8]))
+        return 0
+    print("check-branch-current: %s" % found, file=sys.stderr)
+    return 1
+
+
+if __name__ == "__main__":
+    raise SystemExit(main(sys.argv[1:]))

boost_skill_cli-1.2.35/tests/unit/test_branch_current.py

@@ -0,0 +1,56 @@
+# Copyright the boost contributors.
+# SPDX-License-Identifier: GPL-3.0-only
+"""A pull request that does not contain main's tip cannot merge.
+
+This is the check that would have stopped the red `main` of 2026-08-29. Two
+pull requests were each green against the `main` they were tested on, and the
+second merged without re-testing against the first. Their source files did not
+conflict; their *generated* roadmap board did, and a squash merge takes one
+side of a generated file without ever reporting a conflict.
+
+GitHub can enforce this natively, and the repository asks it to twice — but
+classic branch protection has `enforce_admins: false`, so it does not apply to
+the one account that merges, and the active ruleset has
+`strict_required_status_checks_policy: false`. Between them, nothing was
+enforcing it. A required *check* is enforced by the ruleset regardless, which
+is why this lives in the repository rather than in a settings page.
+"""
+from __future__ import annotations
+
+import importlib.util
+from pathlib import Path
+
+import pytest
+
+ROOT = Path(__file__).resolve().parents[2]
+_SCRIPT = ROOT / "scripts" / "check_branch_current.py"
+
+
+def _mod():
+    spec = importlib.util.spec_from_file_location("check_branch_current", _SCRIPT)
+    assert spec and spec.loader
+    module = importlib.util.module_from_spec(spec)
+    spec.loader.exec_module(module)
+    return module
+
+
+def test_a_branch_containing_main_is_fine() -> None:
+    assert _mod().problem("abc1234", contains_base=True) is None
+
+
+def test_a_branch_behind_main_is_a_problem() -> None:
+    out = _mod().problem("abc1234", contains_base=False)
+    assert out is not None
+    assert "abc1234" in out, "the message must name the commit to rebase onto"
+
+
+def test_the_problem_names_the_fix() -> None:
+    """A failing check that does not say what to run costs a support round."""
+    out = _mod().problem("abc1234", contains_base=False)
+    assert "git rebase origin/main" in out or "rebase" in out
+
+
+@pytest.mark.parametrize("contains", [True, False])
+def test_verdict_depends_only_on_containment(contains: bool) -> None:
+    """The one input that decides it — nothing environmental leaks in."""
+    assert (_mod().problem("deadbee", contains_base=contains) is None) is contains