#310 was closed as completed, but no Windows test job exists in .github/workflows

**Package:** agent-governance-toolkit-core

## Description

Issue #310 ("test: add Windows compatibility tests to CI") was closed as
`completed` on 2026-04-01. Its first acceptance criterion reads:

> Add `windows-latest` to the test matrix in `.github/workflows/ci.yml`

As of today there is no Windows test job anywhere in `.github/workflows`.

I fetched all 42 workflow files and counted runners:

| runner | jobs |
|---|---|
| `ubuntu-latest` | 98 |
| `ubuntu-24.04` | 1 |
| `${{ matrix.os }}` | 1 |
| any Windows runner in a **test** job | 0 |

The string `windows` appears exactly once in the whole directory, at
`publish.yml:163`:

```yaml
- { os: windows-2022, platform: windows-x86_64, target: x86_64-pc-windows-msvc,
builder: native, wheel: "*win_amd64.whl", macos_target: "" }
```

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.

Happy to open a PR for that job if it would help.

## Steps to Reproduce

1. Clone the repository at current `main`.
2. 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 }}.

3. Search the whole workflow directory for Windows:

grep -riE "windows" .github/workflows/

Result: a single hit, `publish.yml:163`, inside the wheel-building matrix.

4. Open `.github/workflows/ci.yml` (the file named in #310's acceptance
criteria) and confirm it contains no `windows` and no `macos`.

5. Open #310 and confirm it is closed as `completed` with no comments, no
linked PR, and no referencing commit on the timeline.

## Environment

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".

Start with .github/workflows/ci.yml and compare its existing test jobs with the suite entry points they run. Use the supplied grep checks to confirm the current runner coverage, then verify that the Windows test job executes the project tests without changing the wheel-building workflow. Done means a Windows test job is visible in Actions and its status is reported independently of merge gating.

Written by the indexing model from the issue text.