scientific-computing-system 2.2.1__tar.gz → 2.2.3__tar.gz

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/.github/workflows/cli-package-smoke.yml

@@ -33,10 +33,15 @@ jobs:
         with:
           python-version: "3.12"
       - name: Build wheel
+        # bash, not the Windows default PowerShell: `set -euo pipefail` is bash
+        # syntax and pwsh rejects it with "A parameter cannot be found that
+        # matches parameter name 'euo'". The other steps in this job pin the
+        # shell for the same reason.
+        shell: bash
         run: |
-          python -m pip install --upgrade pip
-          pip install build
-          python -m build --wheel
+          set -euo pipefail
+          python -m pip install --require-hashes --only-binary=:all: -r requirements-build.lock
+          python -m build --wheel --no-isolation
       - name: Install wheel instead of source tree
         shell: bash
         run: |

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/.github/workflows/npm-publish.yml

@@ -270,9 +270,25 @@ jobs:
           if npm view "scientific-computing-system@${version}" version >/dev/null 2>&1; then
             echo "::error::scientific-computing-system@${version} is already on npm"
             echo "::error::nothing to do; bump package.json (and the locked version surfaces) to publish again"
+            echo "::error::: read this BEFORE bumping anything ---"
+            echo "::error::npm uses the SAME 404 to mean two different things: a version that is not"
+            echo "::error::published yet, and a caller whose credential is not authorized to see it. An"
+            echo "::error::unregistered trusted publisher is a 404, not a 401/403, because npm will not"
+            echo "::error::tell an unauthenticated caller whether a package exists."
+            echo "::error::A red publish step therefore does NOT by itself mean 'already published'. Do not"
+            echo "::error::burn a release number bumping the version to 'fix' a 404: if the trusted publisher"
+            echo "::error::is unregistered the next version will fail identically, and you will have consumed"
+            echo "::error::a version on both registries for nothing."
             exit 1
           fi
           echo "PASS: scientific-computing-system@${version} is unpublished"
+          # This gate only proves absence. Say so, so its PASS cannot be read as
+          # "and we are authorized to publish it" -- the two are independent and
+          # only the first is tested here.
+          echo "NOTE: absence is all this gate proves. It says nothing about whether this job is"
+          echo "NOTE: authorized to publish: an unregistered trusted publisher also reads as 404. If"
+          echo "NOTE: 'npm publish' below fails with E404, the cause is the publisher registration,"
+          echo "NOTE: not the version."
 
       # Two supported modes, selected by the `use_token_fallback` dispatch input.
       #
@@ -355,9 +371,65 @@ jobs:
           echo "PASS: npm registry auth entry present (value not shown)"
           echo "PASS: the entry references NODE_AUTH_TOKEN by name, not a literal secret"
 
+      # The publish command is unchanged and the step is still fail-closed: a
+      # non-zero npm exit still ends the job with that same exit code. All that is
+      # added is the diagnosis, because npm's bare E404 was ambiguous enough to be
+      # read as a version problem:
+      #
+      #   npm error 404 The requested resource 'scientific-computing-system@2.2.2'
+      #   could not be found or you do not have permission to access it.
+      #
+      # Nothing in that line says which half is true. Observed on runs 37268729425
+      # and 37269325567: the version was genuinely unpublished (the gate above
+      # passed), the tarball built, provenance was signed and submitted to the
+      # Sigstore transparency log, and only then did the PUT 404. An unregistered
+      # trusted publisher is the cause, and "bump the version" would not have
+      # helped.
       - name: Publish to npm (OIDC trusted publishing, with provenance)
         if: ${{ !inputs.use_token_fallback }}
-        run: npm publish --provenance --access public
+        run: |
+          # `-e` is on by default in this shell, so it is explicitly suspended
+          # around npm to capture the exit code instead of aborting before the
+          # log can be inspected.
+          set +e
+          log="${RUNNER_TEMP}/npm-publish.log"
+          npm publish --provenance --access public >"$log" 2>&1
+          status=$?
+          set -e
+          cat "$log"
+
+          if [ "$status" -ne 0 ]; then
+            echo "::error::npm publish failed (exit $status)"
+            if grep -qE 'E404|404 Not Found' "$log"; then
+              echo "::error::: this 404 is NOT a missing package and NOT a wrong version number ---"
+              echo "::error::scientific-computing-system exists on npm, and the gate above just proved"
+              echo "::error::this exact version is absent from it. npm reports an UNAUTHORIZED caller with"
+              echo "::error::the same 404 it uses for 'no such version', so the message cannot tell you"
+              echo "::error::which one you hit. Reading it as a version problem sends you to bump a version"
+              echo "::error::that still cannot publish."
+              echo "::error::If npm signed and submitted provenance above, the OIDC identity was accepted and"
+              echo "::error::the registry rejected the PUT for want of a matching trusted publisher."
+              echo "::error::A rejected or absent TOKEN looks different: 401, or ENEEDAUTH."
+              echo "::error::One-time maintainer fix, not automatable from CI:"
+              echo "::error::  npmjs.com -> package 'scientific-computing-system' -> Settings -> Trusted Publisher"
+              echo "::error::    Organization or user : Furox-Art"
+              echo "::error::    Package             : scientific-computing-system"
+              echo "::error::    Workflow filename   : npm-publish.yml"
+              echo "::error::    Environment name    : npm"
+              echo "::error::    Allowed actions     : npm publish   <-- must be enabled, see below"
+              echo "::error::npm's current UI allows 'npm stage publish' by default for newly created"
+              echo "::error::configurations and makes direct 'npm publish' opt-in. This workflow calls"
+              echo "::error::'npm publish' directly, so registering the publisher WITHOUT also allowing"
+              echo "::error::'npm publish' will still fail -- with a permission error rather than a 404."
+              echo "::error::CLI equivalent, using your own npm login and 2FA:"
+              echo "::error::  npm trust github --file npm-publish.yml \\"
+              echo "::error::    --repo Furox-Art/scientific-computing-system --env npm --allow-publish"
+            else
+              echo "::error::not a 404; see the npm output above for the real cause"
+            fi
+            exit "$status"
+          fi
+          echo "PASS: npm publish returned 0"
 
       - name: Publish to npm (token mode, no provenance)
         if: ${{ inputs.use_token_fallback }}

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/.github/workflows/release.yml

@@ -179,6 +179,20 @@ jobs:
       - name: Build sdist + wheel without dependency isolation
         run: python -m build --no-isolation
 
+      # Validate the core metadata *rendered* from the artifacts, before anything
+      # is uploaded. `check_version_lockstep.py` proves the version and name are
+      # right; it does not prove the artifact is renderable at all. This is the
+      # step that catches an unusable artifact while it is still local.
+      #
+      # The pin matters and is not cosmetic. twine <= 6.2.0 replaces
+      # `packaging.metadata._VALID_METADATA_VERSIONS` at import time with a list
+      # ending at 2.4, so it rejects a valid artifact with
+      # `InvalidDistribution: '2.5' is not a valid metadata version` -- a release
+      # failure with nothing wrong with the package. twine 7.0.0 (pinned in
+      # requirements-build.lock) removed the override.
+      - name: Validate artifact metadata renders
+        run: python -m twine check --strict dist/*
+
       # Assert the *contents* of both artifacts before anything is published.
       # The version/name verification below proves the metadata says 2.1.0; this
       # proves the wheel actually ships `cds` with its `py.typed` marker and the

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/.github/workflows/tests.yml

@@ -307,6 +307,53 @@ jobs:
         run: python scripts/check_version_discipline.py --base-ref "${{ steps.base.outputs.ref }}"
       - name: Reject version metadata lockstep drift
         run: python scripts/check_version_lockstep.py
+      # The release toolchain must stay pinned, and the twine pin must stay able
+      # to validate the Metadata-Version the build backend actually emits --
+      # twine<=6.2.0 overrides packaging's list at import time and rejects valid
+      # artifacts with `'2.5' is not a valid metadata version`.
+      #
+      # GITHUB_TOKEN is passed so the advisory upstream checks authenticate.
+      # Unauthenticated GitHub API calls are capped at 60/hour, which is easy to
+      # exceed and fails in a way that looks like success: a sibling guard
+      # "verified" pins under rate limiting and silently verified nothing.
+      # Fast, offline, workflow-shape gate: pins and `twine check --strict` usage.
+      # The authoritative run, including the twine/Metadata-Version compatibility
+      # check, is in the `packaging` job below -- the only job that has built
+      # artifacts to read the emitted Metadata-Version from.
+      - name: Reject unpinned release toolchain
+        run: python scripts/check_release_toolchain.py --skip-network
+      # The provenance prose asserts, per registry, whether the published
+      # release carries a build attestation. That claim was originally written
+      # from memory and nothing checked it, so it could have kept being
+      # asserted after a release changed the answer. This runs the committed
+      # guard (`docs/checks/verify_provenance_claims.py`) against the live
+      # registries and fails if the prose contradicts them.
+      #
+      # Placed here rather than in a new job on purpose: this job already owns
+      # release-metadata verification and already sits in the required `CI`
+      # aggregate, so this strengthens an existing gate instead of adding a
+      # required check that would need a ruleset change. `permissions:
+      # contents: read` above is sufficient -- the guard only reads PyPI and npm,
+      # never the GitHub API, so no token is needed.
+      #
+      # `--strict-network` is deliberately NOT set: a registry outage is
+      # reported as UNKNOWN and the run passes with a NOTICE, because a required
+      # gate that fails on a DNS blip teaches people to re-run it rather than
+      # read it. A false claim still fails. The unit test
+      # (`tests/test_provenance_claims.py`) is the deterministic gate and needs
+      # no network at all.
+      #
+      # The version is read from `pyproject.toml` rather than hardcoded: a
+      # literal here would go stale at the next release, which is the same class
+      # of stale-constant bug this step exists to catch. A version that has not
+      # shipped yet is reported as unverifiable rather than "unattested", so a
+      # bump PR is not blocked by asking about a release that does not exist.
+      - name: Reject provenance claims that contradict the live registries
+        run: >-
+          python docs/checks/verify_provenance_claims.py
+          --version "$(python -c 'import tomllib, pathlib;
+          print(tomllib.loads(pathlib.Path("pyproject.toml").read_text(encoding="utf-8"))
+          ["project"]["version"])')"
 
   packaging:
     name: built wheel and sdist contents on Linux with Python 3.12
@@ -332,6 +379,19 @@ jobs:
         run: python scripts/check_version_lockstep.py --dist-dir dist
       - name: Assert wheel and sdist contents
         run: python scripts/check_distribution_contents.py dist
+      # Read the Metadata-Version out of the artifacts just built and prove the
+      # pinned twine can validate it. twine<=6.2.0 overrides packaging's
+      # metadata-version list at import time and rejects a valid artifact with
+      # `'2.5' is not a valid metadata version`; a sibling release failed that
+      # way with nothing wrong with the package.
+      #
+      # GITHUB_TOKEN is passed so the advisory upstream checks authenticate.
+      # Unauthenticated GitHub API calls are capped at 60/hour, and under rate
+      # limiting a pin check can silently verify nothing while reporting success.
+      - name: Assert the pinned twine can validate the built metadata
+        env:
+          GITHUB_TOKEN: ${{ github.token }}
+        run: python scripts/check_release_toolchain.py --dist-dir dist
       # A source distribution whose own test suite cannot pass is not a source
       # distribution. 13 release-contract tests used to fail here because
       # `.github/workflows` was missing from the sdist; this step is what keeps

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/CHANGELOG.md

@@ -7,6 +7,244 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+### Distribution status of 2.2.2 — read this before assuming npm has it
+
+The two registries are **not** in the same state for 2.2.2.
+
+| Registry | `2.2.2` | Build attestation |
+|---|---|---|
+| **PyPI** `scientific-computing-system` | **published** | **PEP 740 provenance present** |
+| **npm** `scientific-computing-system` | **NOT published** | none — the version does not exist on npm |
+
+PyPI 2.2.2 is live and carries a PEP 740 attestation. Verified against the live
+registries on 2026-10-05: the PEP 740 per-file provenance endpoint returns
+**HTTP 200** for both files.
+
+```
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  https://pypi.org/integrity/scientific-computing-system/2.2.2/scientific_computing_system-2.2.2-py3-none-any.whl/provenance   # 200
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  https://pypi.org/integrity/scientific-computing-system/2.2.2/scientific_computing_system-2.2.2.tar.gz/provenance               # 200
+```
+
+npm 2.2.2 does not exist. The published npm versions remain `1.0.0`, `2.2.0` and
+`2.2.1`. Nothing about the npm launcher is broken — the publish is blocked on a
+one-time npmjs.com registration, described next.
+
+### Pending: register the npm trusted publisher (one-time, maintainer, in a browser)
+
+npmjs.com has **no trusted publisher** configured for the package
+`scientific-computing-system`. Until one exists, the OIDC path cannot complete a
+publish, and npm publishes no provenance for this package.
+
+The coordinates to enter on npmjs.com → package `scientific-computing-system` →
+**Settings → Trusted Publisher → GitHub Actions**:
+
+| Field | Value |
+|---|---|
+| Organization or user | `Furox-Art` |
+| Package | `scientific-computing-system` |
+| Workflow filename | `npm-publish.yml` |
+| Environment name | `npm` |
+| Allowed actions | **`npm publish`** — must be enabled, see the warning below |
+
+**The allowed-actions field is not optional in practice.** npm's current UI grants
+`npm stage publish` by default on newly created configurations and makes direct
+`npm publish` **opt-in**. This repository's workflow calls `npm publish` directly,
+so registering the publisher *without* also allowing `npm publish` will leave the
+publish failing — with a permission error this time rather than a 404.
+
+The same registration from the CLI, using the maintainer's own npm login and 2FA:
+
+```
+npm trust github --file npm-publish.yml \
+  --repo Furox-Art/scientific-computing-system --env npm --allow-publish
+```
+
+### The publish mode default is unchanged, and was never set to token
+
+The mode is the `workflow_dispatch` input `use_token_fallback`, whose default is
+`false` — that is **OIDC**. There is no `npm_publish_mode` variable; the repository
+has **no Actions variables at all** (none at repository or organization scope), and
+`npm_publish_mode` appears nowhere in the tree. Nothing needs to be switched back:
+OIDC is already the default, and token mode remains an explicit per-run opt-in.
+
+`NPM_TOKEN` does still exist as a repository secret. It is what token mode would
+use, and it should be deleted once the trusted publisher is registered and the
+first OIDC publish has succeeded.
+
+### Fixed: a 404 from npm no longer reads as "already published"
+
+`npm publish` answered
+
+```
+npm error 404 The requested resource 'scientific-computing-system@2.2.2' could not
+be found or you do not have permission to access it.
+```
+
+on runs 37268729425 and 37269325567, and that single line cannot distinguish the
+two real causes. npm deliberately does not tell an unauthenticated caller whether a
+package exists, so **an unregistered trusted publisher is reported as 404, not as
+401 or 403.**
+
+Two failure surfaces were making that expensive to diagnose, and both now say so
+out loud. Neither changes what the workflow does; both only change what it prints.
+
+- **The publish step** now names the real cause when npm returns 404, states that
+  the package exists and the version is absent, prints the npmjs.com fields above,
+  and calls out the `npm publish` allowed-action requirement. A rejected or absent
+  token looks different (401, or `ENEEDAUTH`), and the step says that too.
+- **The version-existence gate** now warns, at the point where it would otherwise
+  tell someone to bump the version, that a 404 also means "unauthorized". Bumping
+  to escape a 404 consumes a release number on both registries and still will not
+  publish while the publisher is unregistered.
+
+Worth recording precisely: in **both** runs the version gate **passed**. The
+tarball built, provenance was signed and submitted to the Sigstore transparency
+log, and only the `PUT` failed. So both runs did prove the authentication failure,
+and the fix is the registration above — not a version bump.
+
+## [v2.2.3] - 2026-10-05
+
+This release exists to exercise the OIDC trusted-publish path, now that the
+npmjs.com trusted publisher for `scientific-computing-system` is registered.
+
+The previous npm 2.2.2 was published in token mode and therefore carries no
+attestation. Nothing about the launcher changed: `src/` is untouched since
+2.2.2, and the only source change in this release is the version string itself.
+
+## [v2.2.2] - 2026-10-05
+
+Clears the last 17 open CodeQL alerts in this repository. None of them was a
+security vulnerability, and **none was a logic defect** — no discarded result, no
+missing `return`. Nothing is suppressed: there is no `# nosec`, no path exclusion
+and no `codeql.config` entry.
+
+### Behaviour change
+
+**One, and it is a removal:** the private path `cds.cli._parser._build_parser` no
+longer resolves.
+
+`_build_parser` was an alias for `build_parser`, kept for backwards
+compatibility. It was defined in `cds.cli._parser` but imported and re-exported by
+`cds.cli.__init__`, so within its own module it was genuinely unreferenced —
+which is exactly what `py/unused-global-variable` reported. The assignment has
+moved to `cds.cli.__init__`, beside its only consumer and inside the `__all__`
+that already exports it.
+
+- `cds.cli._build_parser` is unchanged: still present, still in `__all__`, still
+  the same object as `cds.cli.build_parser`. This is the documented
+  backwards-compatibility surface and it keeps working.
+- `cds.cli._parser._build_parser` is gone. Nothing in this repository referenced
+  it and the name is underscore-private, but a downstream script that reached
+  into the private submodule would break.
+
+There is now a test pinning the alias, because the original defect was that
+nothing asserted it existed.
+
+### Fixed
+
+- **Protocol placeholders are docstrings, not bare `...`.** Nine
+  `py/ineffectual-statement` alerts across `src/cds/ml/model_selection.py`,
+  `src/cds/ml/voting.py` and `src/cds/tools/adapters.py` were the conventional
+  `...` terminating a `typing.Protocol` method. These are false positives in the
+  strict sense: `...` is the documented placeholder for a structurally-typed
+  method whose implementation lives in the real backend module, and no code path
+  executes it. `SoftVotingModel` is the only `@runtime_checkable` one, and
+  `isinstance` against a runtime protocol inspects attribute *presence* without
+  calling the body.
+
+  They became docstrings rather than `pass` because coverage.py excludes an
+  ellipsis-only body but counts `pass`; measured, swapping it in drops those
+  lines from 100% to 75% and breaks the coverage gate. `raise NotImplementedError`
+  has the same coverage problem and would additionally change behaviour if the
+  body were ever reached. `src/cds` already contained nine docstring-only bodies
+  with no alert on any of them.
+
+- **`src/cds/tools/registry.py` imports `importlib` one way.** Three spellings
+  were mixed: `import importlib`, `import importlib.util` and
+  `from importlib import metadata`. The first was fully subsumed by the second.
+  Now `import importlib.metadata` and `import importlib.util`, with call sites
+  fully qualified. Four monkeypatch targets in `tests/` were retargeted to match.
+
+- **Four `py/unnecessary-lambda` alerts in the test suite.** `lambda x: max(x)`
+  and `lambda values: sum(values)` are plain wrappers around a callable; the
+  callables are now passed directly.
+
+- **`tests/test_fitting_bootstrap.py` imports `cds.modeling.fitting` one way.**
+  A module-level `from ... import` coexisted with function-local
+  `import ... as fitting`. The single `import ... as fitting` form is used now and
+  the module-level names are qualified through it.
+
+### Added
+
+- **`tests/test_protocol_placeholders.py`** pins the protocol bodies on the AST,
+  because a docstring-only body and a docstring followed by `pass` compile to
+  almost identical instructions and only the syntax tree tells them apart. It also
+  asserts the placeholder semantics (`None` when called unbound), that
+  `SoftVotingModel` is still a working structural contract, and that every
+  declared signature and annotation still resolves. Negative-controlled against
+  four mutations, all caught: docstring-plus-`pass`, `...` reinstated, body
+  replaced by a real statement, and a statement appended after the docstring.
+
+### Changed
+
+- README's pasted `cds --version` transcript now reads `System version 2.2.2`.
+  Every provenance and attestation statement in `README.md` and `SECURITY.md`
+  still refers to **2.2.1** deliberately: those describe the published release,
+  including its digests, and remain true until a newer one ships.
+
+
+### Fixed
+
+- **Provenance claims are now scoped, measured, and guarded.** A follow-up report
+  asserted that PyPI had no PEP 740 attestation either. Re-measured directly, that
+  is **not** the case, so the previous text was left standing and made precise
+  rather than weakened:
+
+  - PyPI **2.2.1** serves a PEP 740 provenance bundle for **both** the wheel and
+    the sdist (HTTP 200 on the per-file `/integrity/.../provenance` endpoint),
+    and each bundle's `subject` digest equals the `sha256` PyPI publishes for
+    that file. The 404 in the report came from requesting
+    `https://pypi.org/integrity/scientific-computing-system/2.2.1/`, which is a
+    directory, not the per-file endpoint.
+  - npm **2.2.1** has **no** attestation: the attestations endpoint returns 404.
+    This part of the report was correct.
+
+  The security posture is therefore unchanged and more precisely stated. What
+  changed: `SECURITY.md` now separates the three things that were being conflated
+  — a **PEP 740 attestation** (Sigstore-signed, attests *who built this*),
+  **npm `dist.signatures`** (registry transport signing, attests nothing about
+  the build), and a **content digest** (`sha256` on PyPI, `dist.integrity` on
+  npm; pins *which bytes*, not *where they came from*). It lists the published
+  digests to pin, gives the commands that verify them, and states the exact
+  trusted-publisher coordinates still to be registered for npm.
+
+- **Reproducible-build claim scoped to what was actually measured.** Two
+  consecutive builds of the same commit with the same pinned backend produced
+  byte-identical wheel and sdist. Those digests do **not** match the published
+  ones (the release runs a hash-locked Linux toolchain; the check ran elsewhere),
+  so the documentation now claims determinism for a fixed toolchain and
+  explicitly declines to claim the published artifacts are bit-for-bit
+  reproducible from source.
+
+- **npm launcher prerequisite re-verified.** With `cds` absent from `PATH`, the
+  shim proceeds straight to interpreter resolution (`python`/`python3`/`py`) and
+  runs `python -m cds`; it never looks for a `cds` console script. README,
+  `SECURITY.md` and the docs already agreed on this wording, and it is now
+  backed by an explicit check rather than by reading the source.
+
+### Added
+
+- `docs/checks/verify_provenance_claims.py` — a guard that parses the attestation
+  claims out of `README.md` and `SECURITY.md` and compares them against the live
+  registries, failing if the prose asserts something the registries contradict.
+  It also rejects prose that overstates `dist.integrity` as provenance or allows
+  the attested subject to differ from the published digest. Negative-controlled:
+  three false claims (PyPI not attested, npm attested, digest mismatch acceptable)
+  each turn it red. Wiring it into CI is left to the workflow owner; this change
+  is docs-only by scope.
+
 ## [v2.2.1] - 2026-10-04
 
 Documentation and release-surface corrections. **No library behaviour change**:

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/CITATION.cff

@@ -5,7 +5,7 @@ title: "scientific-computing-system"
 # Keep `version` in lockstep with pyproject.toml [project].version and
 # src/cds/_version.py. scripts/check_version_discipline.py and
 # scripts/check_version_lockstep.py enforce this.
-version: 2.2.1
+version: 2.2.3
 authors:
   - name: "Furox-Art"
     email: "furkanarkn1451@gmail.com"
@@ -21,7 +21,7 @@ abstract: >-
 license: MIT
 repository-code: "https://github.com/Furox-Art/scientific-computing-system"
 url: "https://github.com/Furox-Art/scientific-computing-system"
-date-released: "2026-10-04"
+date-released: "2026-10-05"
 keywords:
   - "pure python"
   - "scientific computing"
@@ -50,5 +50,5 @@ preferred-citation:
   authors:
     - name: "Furox-Art"
   year: 2026
-  version: 2.2.1
+  version: 2.2.3
   url: "https://github.com/Furox-Art/scientific-computing-system"

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: scientific-computing-system
-Version: 2.2.1
+Version: 2.2.3
 Summary: A pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, scientific workflows, dimensional analysis, and optional research-data backends. Zero runtime dependencies.
 Project-URL: Homepage, https://github.com/Furox-Art/scientific-computing-system
 Project-URL: Repository, https://github.com/Furox-Art/scientific-computing-system
@@ -146,10 +146,20 @@ The import name is **`cds`** (the distribution is `scientific-computing-system`)
 | **npm** (a launcher shim) | `npm i -g scientific-computing-system` | A thin Node wrapper that runs `python -m cds`. It ships no Python and needs the Python distribution installed so that `python -m cds` resolves. |
 
 Both channels are published at the same version. They are **not** equally
-verifiable: the PyPI release carries a PEP 740 provenance attestation, while the
-currently published npm release does not. Prefer PyPI for anything
-security-sensitive — [SECURITY.md](SECURITY.md#distribution-channels-and-provenance)
-has the per-channel comparison.
+verifiable:
+
+- **PyPI** — carries a **PEP 740 provenance attestation** (Sigstore-signed,
+  binding the file digest to the publishing workflow). Verified on 2.2.1.
+- **npm** — carries **no** attestation; the npmjs.com trusted publisher is not
+  registered yet, so its publish path cannot mint one. npm does expose
+  `dist.integrity` (sha512), which is a content pin, not proof of origin, and
+  `dist.signatures`, which is npm's registry transport signature, not build
+  provenance.
+
+Prefer PyPI for anything security-sensitive.
+[SECURITY.md](SECURITY.md#distribution-channels-and-provenance) has the
+per-channel table, the published digests to pin, the commands to verify them,
+and what to register to close the npm gap.
 
 ## What's inside
 
@@ -259,7 +269,7 @@ The package installs a `cds` command with 13 subcommands:
 
 ```console
 $ cds --version
-System version 2.2.1
+System version 2.2.3
 $ cds constants        # physical constants table
 ```
 

{scientific_computing_system-2.2.1 → scientific_computing_system-2.2.3}/README.md

@@ -50,10 +50,20 @@ The import name is **`cds`** (the distribution is `scientific-computing-system`)
 | **npm** (a launcher shim) | `npm i -g scientific-computing-system` | A thin Node wrapper that runs `python -m cds`. It ships no Python and needs the Python distribution installed so that `python -m cds` resolves. |
 
 Both channels are published at the same version. They are **not** equally
-verifiable: the PyPI release carries a PEP 740 provenance attestation, while the
-currently published npm release does not. Prefer PyPI for anything
-security-sensitive — [SECURITY.md](SECURITY.md#distribution-channels-and-provenance)
-has the per-channel comparison.
+verifiable:
+
+- **PyPI** — carries a **PEP 740 provenance attestation** (Sigstore-signed,
+  binding the file digest to the publishing workflow). Verified on 2.2.1.
+- **npm** — carries **no** attestation; the npmjs.com trusted publisher is not
+  registered yet, so its publish path cannot mint one. npm does expose
+  `dist.integrity` (sha512), which is a content pin, not proof of origin, and
+  `dist.signatures`, which is npm's registry transport signature, not build
+  provenance.
+
+Prefer PyPI for anything security-sensitive.
+[SECURITY.md](SECURITY.md#distribution-channels-and-provenance) has the
+per-channel table, the published digests to pin, the commands to verify them,
+and what to register to close the npm gap.
 
 ## What's inside
 
@@ -163,7 +173,7 @@ The package installs a `cds` command with 13 subcommands:
 
 ```console
 $ cds --version
-System version 2.2.1
+System version 2.2.3
 $ cds constants        # physical constants table
 ```