You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
That is the wheel-building matrix. A win_amd64 wheel is built on a Windows
runner and published; the suite does not run there.
ci.yml specifically — the file #310 names — has 19 jobs, all ubuntu-latest,
and contains no occurrence of windows or macos.
Issue #310 itself has no comments, no linked pull request, and no referencing
commit on its timeline.
Why this matters here specifically. The package docs state "It supports
Python 3.9+ and runs on any platform", the project ships scripts/quickstart.ps1
as the Windows install path and a win_amd64 wheel to PyPI, and the
"By The Numbers" section advertises "2,573+ Tests Passing".
Then on 2026-08-25 #3831 was filed: "Claude Code plugin: governance hooks
silently never fire on Windows (empty audit log)". That is the exact class of
defect a Windows runner is meant to catch, four months after #310 was marked
done. For a governance and policy-enforcement toolkit the gap is sharper than
for an ordinary library: a control that does not fire and leaves an empty audit
log reports success because nothing wrote to it. That failure is invisible to
the operator by construction, which is precisely the situation this project
exists to prevent.
Suggested minimal step. Rather than turning on a full Windows matrix and
drowning in platform failures at once, the cheapest useful move is a separate
non-blocking job that runs the suite on windows-latest and reports without
gating merges. That makes the size of the gap visible before anyone commits to
closing it, and it would have surfaced #3831 in the first run.
Inspected via the public GitHub API and raw.githubusercontent.com on
2026-09-03, against main as of that date. All 42 files under .github/workflows were downloaded and parsed.
What I could not verify: GitHub's code-search API requires a token and
returned 401 for me, so I only inspected public GitHub Actions. I found no azure-pipelines.yml and no .azure/, .pipelines/ or eng/ directory in
the repository root, but I cannot rule out internal CI that is not visible to
me. If Windows testing runs somewhere I cannot see, this issue is simply wrong
and I would be glad to hear it.
How does this impact your work?
I run this class of tooling on Windows. The concrete consequence is #3831:
governance hooks that silently never fire, leaving an empty audit log that
reads as "no violations".
Package: agent-governance-toolkit-core
Description
Issue #310 ("test: add Windows compatibility tests to CI") was closed as
completedon 2026-04-01. Its first acceptance criterion reads:As of today there is no Windows test job anywhere in
.github/workflows.I fetched all 42 workflow files and counted runners:
ubuntu-latestubuntu-24.04${{ matrix.os }}The string
windowsappears exactly once in the whole directory, atpublish.yml:163:That is the wheel-building matrix. A
win_amd64wheel is built on a Windowsrunner and published; the suite does not run there.
ci.ymlspecifically — the file #310 names — has 19 jobs, allubuntu-latest,and contains no occurrence of
windowsormacos.Issue #310 itself has no comments, no linked pull request, and no referencing
commit on its timeline.
Why this matters here specifically. The package docs state "It supports
Python 3.9+ and runs on any platform", the project ships
scripts/quickstart.ps1as the Windows install path and a
win_amd64wheel to PyPI, and the"By The Numbers" section advertises "2,573+ Tests Passing".
Then on 2026-08-25 #3831 was filed: "Claude Code plugin: governance hooks
silently never fire on Windows (empty audit log)". That is the exact class of
defect a Windows runner is meant to catch, four months after #310 was marked
done. For a governance and policy-enforcement toolkit the gap is sharper than
for an ordinary library: a control that does not fire and leaves an empty audit
log reports success because nothing wrote to it. That failure is invisible to
the operator by construction, which is precisely the situation this project
exists to prevent.
Suggested minimal step. Rather than turning on a full Windows matrix and
drowning in platform failures at once, the cheapest useful move is a separate
non-blocking job that runs the suite on
windows-latestand reports withoutgating merges. That makes the size of the gap visible before anyone commits to
closing it, and it would have surfaced #3831 in the first run.
Happy to open a PR for that job if it would help.
Steps to Reproduce
Clone the repository at current
main.Count the runners across every workflow:
grep -h -oE "runs-on:." .github/workflows/.yml | sort | uniq -c
Result: 98 x ubuntu-latest, 1 x ubuntu-24.04, 1 x ${{ matrix.os }}.
Search the whole workflow directory for Windows:
grep -riE "windows" .github/workflows/
Result: a single hit,
publish.yml:163, inside the wheel-building matrix.Open
.github/workflows/ci.yml(the file named in test: add Windows compatibility tests to CI #310's acceptancecriteria) and confirm it contains no
windowsand nomacos.Open test: add Windows compatibility tests to CI #310 and confirm it is closed as
completedwith no comments, nolinked PR, and no referencing commit on the timeline.
Environment
Inspected via the public GitHub API and raw.githubusercontent.com on
2026-09-03, against
mainas of that date. All 42 files under.github/workflowswere downloaded and parsed.What I could not verify: GitHub's code-search API requires a token and
returned 401 for me, so I only inspected public GitHub Actions. I found no
azure-pipelines.ymland no.azure/,.pipelines/oreng/directory inthe repository root, but I cannot rule out internal CI that is not visible to
me. If Windows testing runs somewhere I cannot see, this issue is simply wrong
and I would be glad to hear it.
How does this impact your work?
I run this class of tooling on Windows. The concrete consequence is #3831:
governance hooks that silently never fire, leaving an empty audit log that
reads as "no violations".