Cleanups in the cross-subsystem gaps

[Xof]

This issue groups 2 related findings.

GAP-2 — The published Python distribution declares MIT but ships no license text — the LICENSE file lives at the repo root, outside the sdist/wheel build context

Location: python/pyproject.toml:11, python/pyproject.toml:30, LICENSE:1, .github/workflows/wheels.yml:113 · Severity: SMELL · Category: cargo-hygiene

What the code does. python/pyproject.toml:11 declares license = { text = "MIT" }, and [tool.maturin] include at :30-32 lists exactly two extra files — chisel/py.typed and chisel/chisel.pyi. There is no license-files key and no LICENSE file anywhere under python/ (the only copy is the repo-root LICENSE). The wheels workflow builds the sdist with working-directory: python (.github/workflows/wheels.yml:112-115) and builds wheels with package-dir: python, so the root LICENSE is never in scope for either artifact.

Why it is a problem. Every wheel and sdist published to PyPI carries the metadata string "MIT" with no accompanying license text, which fails the MIT license's own condition that "the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software" (LICENSE:10-11). Downstream vendoring and corporate license-scanning tooling that reads the distribution rather than the GitHub repo sees an unlicensed artifact. Nothing in CI checks this; the Rust crate is unaffected because cargo picks up the root LICENSE automatically.

Direction of a fix. Add a copy (or symlink resolved at build time) of LICENSE under python/ and reference it from [tool.maturin] include and/or [project] license-files, so both the wheel and the sdist carry the text.

GAP-3 — The release workflow ties nothing to the tag it fires on: no version check across the three manifests, and the sdist is uploaded without ever being built from

Location: .github/workflows/wheels.yml:5, .github/workflows/wheels.yml:100, .github/workflows/wheels.yml:115, python/pyproject.toml:7, Cargo.toml:36 · Severity: SMELL · Category: ci

What the code does. wheels.yml fires on tags: ["v*"] (:5). The gate job runs cargo test --release and cargo audit (:24, :32); the wheel job runs CIBW_TEST_COMMAND: pytest {package}/tests against each built wheel. No step compares the tag to the versions in Cargo.toml:36 (0.1.0), python/Cargo.toml (0.1.0), or python/pyproject.toml:7 (0.1.0). Separately, the sdist job (:100-120) runs maturin sdist -o ../dist and uploads the tarball (:117-120) with no step that installs or compiles it.

Why it is a problem. Tagging v0.2.0 today produces and uploads wheels and an sdist whose internal version is 0.1.0 — silently mislabeled release artifacts, with no CHANGELOG in the repo to catch the discrepancy by eye. And the sdist is the one artifact whose build is genuinely fragile here: python/Cargo.toml has chisel = { path = ".." }, a path dependency that resolves outside the sdist's own directory, so an sdist that fails to compile at pip install time on a user's machine ships green because CI never attempts it (the wheel job's CIBW_TEST_COMMAND exercises wheels only).

Direction of a fix. Add a step to the cargo-test-gate job asserting ${GITHUB_REF_NAME#v} equals the version in all three manifests, and add a verification step to the sdist job that does pip install dist/*.tar.gz && pytest tests in a clean venv before upload.

---

_{Filed from the clean-slate deep review of 2026-07-29. Full context, verification notes, and the delta against ISSUES.md are in docs/reviews/review-20260729-183138.md. Baseline at review time: 681 tests passing, clippy and fmt clean — none of these are toolchain-visible.}