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

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/.github/workflows/changelog.yml

@@ -53,7 +53,7 @@ jobs:
           fetch-depth: 0
 
       - name: Install git-cliff
-        uses: orhun/git-cliff-action@3d96a18cc4ec17e9dc69ddcc424ccafaf1f78ce2 # v4
+        uses: orhun/git-cliff-action@a9a95522b26fe6403f7bb24031f21fb573d0f5ff # v4
         with:
           config: cliff.toml
           args: --verbose --tag ${{ inputs.tag }} --output CHANGELOG.md

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/.github/workflows/codeql.yml

@@ -43,13 +43,13 @@ jobs:
         with:
           persist-credentials: false
       - name: Initialize CodeQL
-        uses: github/codeql-action/init@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4
+        uses: github/codeql-action/init@2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2 # v4
         with:
           languages: ${{ matrix.language }}
           queries: security-and-quality
       - name: Autobuild
-        uses: github/codeql-action/autobuild@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4
+        uses: github/codeql-action/autobuild@2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2 # v4
       - name: Perform CodeQL Analysis
-        uses: github/codeql-action/analyze@1c5b675653bb5c22dbe9b12b556ec555138e09fd # v4
+        uses: github/codeql-action/analyze@2892aa5e19bbd11bc0cff5427e3b750a04d9e3c2 # v4
         with:
           category: "/language:${{ matrix.language }}"

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

@@ -37,8 +37,10 @@ name: npm Publish
 # cannot work or pretending an attestation was produced.
 #
 # Both modes are fail-closed. A requested mode with no usable credential exits 1
-# with an actionable message. Token mode never runs automatically, so a broken
-# OIDC configuration cannot silently downgrade to the long-lived credential.
+# with an actionable message. The automatic release-tag path deliberately uses
+# the repository's verified NPM_TOKEN until npm Trusted Publishing is registered.
+# Manual workflow_dispatch runs still default to OIDC so that path can be tested
+# and adopted later without changing the release topology.
 
 on:
   workflow_dispatch:
@@ -53,21 +55,11 @@ on:
         type: boolean
         default: false
   push:
-    # `branches` and `tags` in one `push` mapping are OR'd by GitHub.
-    #
-    # The `v*` tag is the release path: release.yml creates the tag only after
-    # the PyPI publish has succeeded, so a single version bump reaches PyPI
-    # first and npm second. `paths` narrows *branch* pushes so unrelated merges
-    # do not run this job; GitHub does not evaluate `paths` against tag pushes.
-    branches: [main]
+    # release.yml creates the version tag only after the PyPI release succeeds.
+    # Publishing npm from that tag gives one version bump exactly one automatic
+    # npm run, avoiding the previous branch-push + tag-push duplicate race.
     tags:
       - "v*"
-    paths:
-      - "package.json"
-      - "index.js"
-      - "bin/**"
-      - "npm.test.js"
-      - ".github/workflows/npm-publish.yml"
 
 concurrency:
   group: npm-publish
@@ -120,7 +112,7 @@ jobs:
       # ENEEDAUTH; with the entry present it reaches the registry and fails
       # E401 on a deliberately fake token instead.
       - name: Set up Node
-        uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
+        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
         with:
           node-version: "24"
           registry-url: "https://registry.npmjs.org"
@@ -325,14 +317,20 @@ jobs:
           NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |
           set -euo pipefail
-          if [ "${{ inputs.use_token_fallback }}" = "true" ]; then
+          if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
+            requested_token="${{ inputs.use_token_fallback }}"
+          else
+            requested_token="true"
+          fi
+
+          if [ "$requested_token" = "true" ]; then
             if [ -z "${NPM_TOKEN:-}" ]; then
-              echo "::error::token mode was requested (use_token_fallback=true) but the NPM_TOKEN secret is empty or unset"
-              echo "::error::add an npm automation token as the NPM_TOKEN secret, or re-run without use_token_fallback once the npmjs.com trusted publisher is registered"
+              echo "::error::token mode was requested but the NPM_TOKEN secret is empty or unset"
+              echo "::error::add an npm automation token as the NPM_TOKEN secret, or use a manual OIDC dispatch after registering the npm trusted publisher"
               exit 1
             fi
             echo "mode=token via NPM_TOKEN (no provenance: a long-lived token cannot mint a Sigstore attestation)"
-            echo "::warning::Publishing with NPM_TOKEN instead of OIDC. Register the npmjs.com trusted publisher and delete NPM_TOKEN once this release is out."
+            echo "::warning::Automatic release-tag publishing uses NPM_TOKEN until npm Trusted Publishing is registered."
           else
             if [ -z "${ACTIONS_ID_TOKEN_REQUEST_URL:-}" ] || [ -z "${ACTIONS_ID_TOKEN_REQUEST_TOKEN:-}" ]; then
               echo "::error::OIDC mode was requested but this job cannot mint an OIDC token"
@@ -386,7 +384,7 @@ jobs:
       # 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 }}
+        if: ${{ github.event_name == 'workflow_dispatch' && !inputs.use_token_fallback }}
         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
@@ -432,7 +430,7 @@ jobs:
           echo "PASS: npm publish returned 0"
 
       - name: Publish to npm (token mode, no provenance)
-        if: ${{ inputs.use_token_fallback }}
+        if: ${{ github.event_name != 'workflow_dispatch' || inputs.use_token_fallback }}
         env:
           NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
         run: |

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

@@ -416,7 +416,7 @@ jobs:
         with:
           persist-credentials: false
       - name: Set up Node
-        uses: actions/setup-node@a0853c24544627f65ddf259abe73b1d18a591444 # v5.0.0
+        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
         with:
           node-version: "24"
       # `node --check` runs standalone here as well as via the npm `pretest`

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

@@ -104,6 +104,14 @@ 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.4] - 2026-10-12
+
+### Housekeeping — release alignment
+
+- Publishes the post-2.2.3 repository state (single-shot automatic npm
+  publishing, #165) to PyPI and npm: the 2.2.3 upload predates that commit, so
+  both registries were one commit behind `main`. No behavioural change.
+
 ## [v2.2.3] - 2026-10-05
 
 This release exists to exercise the OIDC trusted-publish path, now that the

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/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.3
+version: 2.2.4
 authors:
   - name: "Furox-Art"
     email: "furkanarkn1451@gmail.com"
@@ -50,5 +50,5 @@ preferred-citation:
   authors:
     - name: "Furox-Art"
   year: 2026
-  version: 2.2.3
+  version: 2.2.4
   url: "https://github.com/Furox-Art/scientific-computing-system"

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: scientific-computing-system
-Version: 2.2.3
+Version: 2.2.4
 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
@@ -149,14 +149,17 @@ Both channels are published at the same version. They are **not** equally
 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.
+  binding the file digest to the publishing workflow). Verified on 2.2.3, and
+  on every release since attestations were enabled.
+- **npm** — carries a **Sigstore attestation as of 2.2.3**, minted by npm's
+  OIDC trusted publisher (the registry serves both an npm publish attestation
+  and a SLSA provenance v1 bundle for that tarball). 1.0.0 through 2.2.2
+  predate the publisher registration and have none, so pin 2.2.3 or newer. npm
+  also exposes `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 if you need an attestation for a version older than 2.2.3.
 [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.

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

@@ -53,14 +53,17 @@ Both channels are published at the same version. They are **not** equally
 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.
+  binding the file digest to the publishing workflow). Verified on 2.2.3, and
+  on every release since attestations were enabled.
+- **npm** — carries a **Sigstore attestation as of 2.2.3**, minted by npm's
+  OIDC trusted publisher (the registry serves both an npm publish attestation
+  and a SLSA provenance v1 bundle for that tarball). 1.0.0 through 2.2.2
+  predate the publisher registration and have none, so pin 2.2.3 or newer. npm
+  also exposes `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 if you need an attestation for a version older than 2.2.3.
 [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.

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/SECURITY.md

@@ -29,8 +29,8 @@ It is also published to npm as `scientific-computing-system`, but that package i
 
 | Threat | Mitigation |
 |---|---|
-| **Supply chain: malicious or substituted PyPI artifact** | The release workflow is the sole PyPI publish authority. It builds wheel + sdist on a GitHub-hosted runner from a hash-pinned toolchain, verifies package metadata/version, installs the built wheel, smoke-tests the installed CLI, and publishes through PyPI Trusted Publishing (OIDC). PyPI serves a PEP 740 provenance bundle for 2.2.1 whose subject digest matches the published `sha256`. |
-| **Supply chain: malicious or substituted npm artifact** | The npm workflow is the sole npm publish authority and gates on the registry version-existence check, a `npm pack --dry-run` tarball allowlist, and npm/Python version lockstep. **No attestation is possible yet:** the npmjs.com trusted publisher is not registered, so the token fallback is the working mode and npm's `--provenance` cannot be honoured. Consumers can only pin `dist.integrity` until that is registered. See below. |
+| **Supply chain: malicious or substituted PyPI artifact** | The release workflow is the sole PyPI publish authority. It builds wheel + sdist on a GitHub-hosted runner from a hash-pinned toolchain, verifies package metadata/version, installs the built wheel, smoke-tests the installed CLI, and publishes through PyPI Trusted Publishing (OIDC). PyPI serves a PEP 740 provenance bundle for 2.2.3 whose subject digest matches the published `sha256`. |
+| **Supply chain: malicious or substituted npm artifact** | The npm workflow is the sole npm publish authority and gates on the registry version-existence check, a `npm pack --dry-run` tarball allowlist, and npm/Python version lockstep. **2.2.3 onward is attested:** the npmjs.com trusted publisher is registered, the workflow publishes in `mode=oidc`, and npm's `--provenance` is honoured, so the registry serves an npm publish attestation plus a SLSA provenance v1 bundle for the released tarball. **1.0.0–2.2.2 are not:** they were published through the token fallback, which cannot mint an attestation, so for those versions the only consumer-side control is `dist.integrity`, which is a content pin rather than proof of origin. See below. |
 | **Registry drift** | Public PyPI is treated as the distribution registry for the library. The release integrity check requires exactly one wheel and one sdist on PyPI and requires the matching GitHub Release to contain no wheel/sdist assets. A registry-policy workflow rechecks the public PyPI package and removes accidental distribution assets from GitHub Releases. |
 | **Dependency vulnerabilities** | The core has no required runtime dependencies. Development/test/docs lock files are audited in CI with `pip-audit`; optional backends are isolated behind extras and lazy loading. |
 | **Code execution from package install** | The build backend is `hatchling`; there is no `setup.py` execution and package versioning is static in `pyproject.toml` plus `src/cds/_version.py`. |
@@ -48,8 +48,8 @@ version-specific; re-check it rather than trusting it indefinitely.
 |---|---|---|
 | Contents | the library (wheel + sdist) | `index.js`, `bin/scs.js`, `LICENSE`, `README.md`, `CHANGELOG.md`, `SECURITY.md` — **no Python** |
 | Requires the other channel | no | yes; `scs` runs `python -m cds`, so the Python distribution must be installed. It resolves `python`/`python3`/`py` and does **not** look for a `cds` console script on `PATH` |
-| Publish authentication | Trusted Publishing (OIDC) | OIDC trusted publishing implemented and default; token fallback exists |
-| **PEP 740 provenance attestation** | **yes on 2.2.1** (verified; see below) | **none** — attestations endpoint returns 404 |
+| Publish authentication | Trusted Publishing (OIDC) | Trusted Publishing (OIDC) since 2.2.3; token fallback still exists in the workflow |
+| **PEP 740 provenance attestation** | **yes on 2.2.3** (verified; see below) | **yes on 2.2.3** (verified; see below) |
 | **npm `dist.signatures`** | n/a | present — registry transport signature, **not** build provenance |
 | **Content digest a consumer can pin** | `sha256` per file on the PyPI file page | `dist.integrity` (sha512) and `dist.shasum` (sha1) |
 
@@ -69,34 +69,40 @@ version-specific; re-check it rather than trusting it indefinitely.
 
 #### What is published today, and how to check it
 
-Verified against the live registries for **PyPI 2.2.1**:
+Verified against the live registries for **2.2.3** on 2026-10-05:
 
 ```bash
 # PEP 740 attestation exists (HTTP 200). Note the per-FILE path; a bare
 # /integrity/<project>/<version>/ directory is not an endpoint and 404s.
 curl -sS -H "Accept: application/vnd.pypi.integrity.v1+json" \
-  https://pypi.org/integrity/scientific-computing-system/2.2.1/scientific_computing_system-2.2.1-py3-none-any.whl/provenance
+  https://pypi.org/integrity/scientific-computing-system/2.2.3/scientific_computing_system-2.2.3-py3-none-any.whl/provenance
 
 # The digest PyPI publishes for that file, to compare against the attestation
 # subject (predicateType https://docs.pypi.org/attestations/publish/v1):
-curl -sS https://pypi.org/pypi/scientific-computing-system/2.2.1/json | python -c \
+curl -sS https://pypi.org/pypi/scientific-computing-system/2.2.3/json | python -c \
   "import json,sys; [print(f['filename'], f['digests']['sha256']) for f in json.load(sys.stdin)['urls']]"
 
-# npm: no attestation; there IS a transport signature and an integrity digest.
+# npm: attested from 2.2.3 onward (HTTP 200, two bundles: the npm publish
+# attestation and a SLSA provenance v1 one). Earlier versions 404 -- 1.0.0,
+# 2.2.0, 2.2.1 and 2.2.2 were published through the token fallback, which
+# cannot mint an attestation.
 curl -sS -o /dev/null -w '%{http_code}\n' \
-  https://registry.npmjs.org/-/npm/v1/attestations/scientific-computing-system@2.2.1   # -> 404
-npm view scientific-computing-system@2.2.1 dist.integrity dist.shasum
+  https://registry.npmjs.org/-/npm/v1/attestations/scientific-computing-system@2.2.3   # -> 200
+curl -sS -o /dev/null -w '%{http_code}\n' \
+  https://registry.npmjs.org/-/npm/v1/attestations/scientific-computing-system@2.2.2   # -> 404
+npm view scientific-computing-system@2.2.3 dist.integrity dist.shasum
 ```
 
-The published PyPI 2.2.1 digests, useful for pinning:
+The published PyPI 2.2.3 digests, useful for pinning:
 
 | File | sha256 |
 |---|---|
-| `scientific_computing_system-2.2.1-py3-none-any.whl` | `b14b89478fdc8b11482ffd556bb6eb59c6b21887f2a09418edec7029d4569bb9` |
-| `scientific_computing_system-2.2.1.tar.gz` | `6ba4ad4c2ebb6bef86356bcbcd251e12978737945e58d9e75b9c68860efa77f6` |
+| `scientific_computing_system-2.2.3-py3-none-any.whl` | `57408c812ac153e6f2dca6345d715084032fc67c5a8d9df127f257c6bfe31a3c` |
+| `scientific_computing_system-2.2.3.tar.gz` | `86af9fa7295d7c026f1b417a48eda4b6a696e9e9605ca459e48ad125a1ab962b` |
 
 Both were confirmed to equal the `subject` digest inside their attestation
 bundles, so the attested bytes and the published bytes are the same bytes.
+The 2.2.1 digests remain pinned in the release notes for that version.
 
 #### Reproducible builds: what is and is not claimed
 
@@ -114,28 +120,29 @@ deterministic for a fixed toolchain, and this repository does not currently
 claim that the published artifacts are bit-for-bit reproducible from source.*
 Treat the published digests above as the pin to use, not a rebuild target.
 
-#### When provenance will appear
+#### How the npm attestation was enabled
 
-The OIDC plumbing is implemented on both sides; the registries-side trusted
-publisher records are **not yet in place**, so an npm release cannot carry an
-attestation yet:
+Both registries now have their trusted-publisher record, so a release from this
+repository's publish workflows mints an attestation on each channel:
 
 - **PyPI** — Trusted Publisher: owner `Furox-Art`, repository
   `scientific-computing-system`, workflow `release.yml`, environment `pypi`.
-  Already exercised: 2.2.1 was published through it and is attested.
+  Exercised since 2.2.1; every release since is attested.
 - **npm** — Trusted Publisher: owner `Furox-Art`, repository
   `scientific-computing-system`, workflow `npm-publish.yml`, environment `npm`.
-  **Pending registration.** Until it exists, the default OIDC path cannot
-  complete a publish, and the token fallback — which cannot mint a Sigstore
-  identity — is the only working mode. That is why the published npm artifacts
-  have no attestation.
-
-  Register it under **Settings → Trusted Publisher → GitHub Actions** and enable
-  the **`npm publish`** allowed action. That last field is not optional here: npm's
-  current UI allows `npm stage publish` by default on new configurations and makes
-  direct `npm publish` opt-in, while this repository's workflow publishes
-  directly. A publisher registered without it still fails, with a permission error
-  rather than a 404.
+  Registered before 2.2.3, which is the first npm release published through it
+  with `--provenance`. Before that registration the default OIDC path could not
+  complete a publish, so 1.0.0–2.2.2 went out through the token fallback — a
+  long-lived token has no OIDC identity to attest, and those versions carry no
+  attestation. They stay in the registry as-is; the fix for a consumer is to
+  move to 2.2.3 or newer.
+
+  The registration step that is easy to miss: under **Settings → Trusted
+  Publisher → GitHub Actions**, the **`npm publish`** allowed action must be
+  enabled. npm's UI allows `npm stage publish` by default on new configurations
+  and makes direct `npm publish` opt-in, while this repository's workflow
+  publishes directly. A publisher registered without it still fails, with a
+  permission error rather than a 404.
 
   **A missing registration looks like a missing version.** npm will not disclose
   whether a package exists to an unauthenticated caller, so an unrecognised
@@ -150,10 +157,11 @@ attestation yet:
   differently — `401`, or `ENEEDAUTH` — so `E404` on a PUT for a package that is
   known to exist means the registration, not the version.
 
-**Practical consequence:** for anything security-sensitive, install from PyPI and
-check the PEP 740 bundle against the digests PyPI publishes. Do not rely on the
-npm channel for supply-chain assurance today; treat its `dist.integrity` as an
-integrity pin only.
+**Practical consequence:** install 2.2.3 or newer from either channel and verify
+its attestation bundle — PEP 740 on PyPI (per-file endpoint), the npm publish and
+SLSA provenance bundles on npm. For a pinned older version the npm channel only
+offers `dist.integrity`, which is an integrity pin and not proof of origin; use
+PyPI's PEP 740 bundle there instead.
 
 ### Optional Backend Boundary
 

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/codemeta.json

@@ -2,7 +2,7 @@
   "@context": "https://doi.org/10.5063/schema/codemeta-2.0",
   "@type": "SoftwareSourceCode",
   "name": "scientific-computing-system",
-  "version": "2.2.3",
+  "version": "2.2.4",
   "description": "Pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, and scientific workflows. Zero runtime dependencies. This is the front door; scientific-computing-system-2.0 is the NumPy build of the same work.",
   "license": "https://spdx.org/licenses/MIT",
   "codeRepository": "https://github.com/Furox-Art/scientific-computing-system",

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/npm.test.js

@@ -278,6 +278,16 @@ test('the npm publish path is armed', () => {
   );
 });
 
+test('automatic npm publishing is single-shot from release tags', () => {
+  const workflow = workflowBody('npm-publish.yml');
+  assert.ok(/tags:\s*\n\s*- "v\*"/.test(workflow), 'v* tags must trigger npm publishing');
+  assert.ok(!/branches:\s*\[main\]/.test(workflow), 'main branch pushes must not duplicate the tag release');
+  assert.ok(
+    /github\.event_name != 'workflow_dispatch' \|\| inputs\.use_token_fallback/.test(workflow),
+    'automatic tag runs must select the verified token path',
+  );
+});
+
 test('both publish modes exist and are selected by one input', () => {
   const workflow = workflowBody('npm-publish.yml');
 
@@ -296,19 +306,18 @@ test('both publish modes exist and are selected by one input', () => {
     'use_token_fallback must default to false so OIDC remains the default mode',
   );
 
-  // Both modes must be present and mutually exclusive.
+  // Both modes must be present and mutually exclusive. Automatic tag releases
+  // use the verified token path; manual dispatches remain available for OIDC.
   const publishSteps = workflow.split('- name: ').filter((block) => /^Publish to npm/.test(block));
   assert.strictEqual(publishSteps.length, 2, 'there must be exactly two publish steps');
-  // Exactly one step runs per mode. The token gate is matched with the `!`
-  // prefix excluded explicitly: `/inputs\.use_token_fallback/` on its own also
-  // matches the OIDC step's `!inputs.use_token_fallback`, which would let both
-  // modes pass a loose assertion while being mutually exclusive in reality.
-  const oidcStep = publishSteps.find((s) => /if:.*!inputs\.use_token_fallback/.test(s));
+  const oidcStep = publishSteps.find(
+    (s) => /github\.event_name == 'workflow_dispatch'/.test(s) && /!inputs\.use_token_fallback/.test(s),
+  );
   const tokenStep = publishSteps.find(
-    (s) => /if:.*inputs\.use_token_fallback/.test(s) && !/!inputs\.use_token_fallback/.test(s),
+    (s) => /github\.event_name != 'workflow_dispatch'/.test(s) && /inputs\.use_token_fallback/.test(s),
   );
-  assert.ok(oidcStep, 'the OIDC publish step must be gated on !inputs.use_token_fallback');
-  assert.ok(tokenStep, 'the token publish step must be gated on inputs.use_token_fallback');
+  assert.ok(oidcStep, 'manual OIDC publish must remain available');
+  assert.ok(tokenStep, 'automatic tag publishing must use the token path');
   assert.notStrictEqual(oidcStep, tokenStep, 'the two modes must be distinct steps');
 
   // The token step must read the repository's existing NPM_TOKEN secret.
@@ -333,8 +342,12 @@ test('the token mode does not request provenance', () => {
     .split('- name: ')
     .filter((block) => /^Publish to npm/.test(block));
 
-  const oidc = publishSteps.find((s) => /!inputs\.use_token_fallback/.test(s));
-  const token = publishSteps.find((s) => /inputs\.use_token_fallback/.test(s) && !/!inputs/.test(s));
+  const oidc = publishSteps.find(
+    (s) => /github\.event_name == 'workflow_dispatch'/.test(s) && /!inputs\.use_token_fallback/.test(s),
+  );
+  const token = publishSteps.find(
+    (s) => /github\.event_name != 'workflow_dispatch'/.test(s) && /inputs\.use_token_fallback/.test(s),
+  );
   assert.ok(oidc, 'OIDC publish step not found');
   assert.ok(token, 'token publish step not found');
 
@@ -550,8 +563,10 @@ test('a missing credential exits before any publish step can run', () => {
     'the preflight must check OIDC availability for OIDC mode',
   );
   assert.ok(
-    /if \[ "\$\{\{ inputs\.use_token_fallback \}\}" = "true" \]; then/.test(preflightBlock),
-    'the preflight must branch on the use_token_fallback input',
+    /github\.event_name/.test(preflightBlock) &&
+      /requested_token/.test(preflightBlock) &&
+      /inputs\.use_token_fallback/.test(preflightBlock),
+    'the preflight must select token mode automatically for tag pushes and honor the manual input',
   );
 
   // Exactly two `exit 1`s: one per mode. Each failing branch must terminate

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/package.json

@@ -1,6 +1,6 @@
 {
   "name": "scientific-computing-system",
-  "version": "2.2.3",
+  "version": "2.2.4",
   "description": "Scientific Computing System launcher - a thin Node wrapper that forwards to the pure-Python `cds` CLI. This npm package ships NO Python code: it requires the Python distribution to be installed (`pip install scientific-computing-system`), otherwise `scs` exits non-zero with an actionable message.",
   "main": "index.js",
   "bin": {

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/pyproject.toml

@@ -2,7 +2,7 @@
 # Distribution name. Formerly published as "cognitive-discovery-system";
 # the import name stays `cds`. Keep the old PyPI project alive as an alias.
 name = "scientific-computing-system"
-version = "2.2.3"
+version = "2.2.4"
 description = "A pure-Python computational science platform for numerical methods, modeling, validation, uncertainty, scientific workflows, dimensional analysis, and optional research-data backends. Zero runtime dependencies."
 readme = "README.md"
 license = "MIT"

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/src/cds/_version.py

@@ -5,5 +5,5 @@ from __future__ import annotations
 
 __all__ = ["__version__", "version", "__version_tuple__", "version_tuple"]
 
-__version__ = version = "2.2.3"
+__version__ = version = "2.2.4"
 __version_tuple__ = version_tuple = (2, 2, 0)

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.4}/tests/test_provenance_claims.py

@@ -289,19 +289,19 @@ def test_npm_dist_handles_failure(monkeypatch: pytest.MonkeyPatch) -> None:
 
 
 def test_security_table_row_parses_to_the_measured_verdict() -> None:
-    """SECURITY.md's real row must parse to (True, False) today."""
+    """SECURITY.md's real row must parse to (True, True) today."""
     pypi_claim, npm_claim, row = guard.read_attestation_row()
 
     assert row, "the attestation row disappeared from SECURITY.md"
     assert pypi_claim is True
-    assert npm_claim is False
+    assert npm_claim is True
 
 
-def test_readme_npm_bullet_parses_to_no_attestation() -> None:
+def test_readme_npm_bullet_parses_to_an_attestation() -> None:
     readme_claim, line = guard.read_readme_npm_claim()
 
     assert line, "the README npm bullet disappeared"
-    assert readme_claim is False
+    assert readme_claim is True
 
 
 @pytest.mark.parametrize(
@@ -332,7 +332,9 @@ def test_prose_claims_scan_finds_the_expected_signals() -> None:
     assert claims["mentions_npm_attestation_status"]
     assert claims["distinguishes_npm_transport_sig"]
     assert claims["distinguishes_digest_from_provenance"]
-    assert claims["states_registration_pending"]
+    # Both trusted publishers are registered and 2.2.3 is attested on npm, so the
+    # prose must no longer claim a pending registration.
+    assert not claims["states_registration_pending"]
 
 
 def test_scan_notes_find_claims_in_the_tree() -> None:
@@ -361,12 +363,14 @@ def test_main_fails_when_no_claim_is_present(
 def test_strict_network_escalates_outage(monkeypatch: pytest.MonkeyPatch) -> None:
     """`--strict-network` turns an unreadable registry into a failure."""
     monkeypatch.setattr(guard, "pypi_attested", lambda *a: (guard.UNKNOWN, "unreachable"))
-    monkeypatch.setattr(guard, "npm_attested", lambda *a: (guard.NO, "404"))
+    # npm answers normally: the outage under test is PyPI's, and a contradictory
+    # npm answer would fail for the wrong reason (the docs claim npm is attested).
+    monkeypatch.setattr(guard, "npm_attested", lambda *a: (guard.YES, "200"))
     monkeypatch.setattr(guard, "npm_dist", lambda *a: (True, "dist.integrity=True"))
     monkeypatch.setattr(guard, "pypi_published_digest", lambda *a: None)
 
-    assert guard.main(["--version", "2.2.1", "--strict-network"]) == 1
-    assert guard.main(["--version", "2.2.1"]) == 0
+    assert guard.main(["--version", "2.2.3", "--strict-network"]) == 1
+    assert guard.main(["--version", "2.2.3"]) == 0
 
 
 def test_decoding_rejects_a_bundle_without_a_subject() -> None: