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

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.5}/.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.5}/.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.5}/.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.5}/.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.5}/CHANGELOG.md

@@ -5,6 +5,15 @@ All notable changes to **scientific-computing-system** will be documented in thi
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [v2.2.5] - 2026-10-12
+### Housekeeping — audit hardening
+
+- Closes the findings of the full-repository audit: patched the concrete
+  defects (correctness, fail-closed behaviour, platform independence),
+  wired every standalone guard into CI, removed dead or duplicated code
+  paths, and pinned every doc claim to a test so it cannot silently
+  drift again. Regression tests fail without the corresponding fix.
+
 ## [Unreleased]
 
 ### Distribution status of 2.2.2 — read this before assuming npm has it
@@ -104,6 +113,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.5}/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.5
 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.5
   url: "https://github.com/Furox-Art/scientific-computing-system"

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: scientific-computing-system
-Version: 2.2.3
+Version: 2.2.5
 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.5}/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.5}/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.5}/benchmarks/run_benchmarks.py

@@ -18,7 +18,6 @@ report stays deterministic.
 
 import json
 import math
-import multiprocessing
 import subprocess
 import time
 import timeit
@@ -199,12 +198,12 @@ def bench_montecarlo() -> OrderedDict[str, str]:
 
     start = time.perf_counter()
     result = estimate_pi(samples, seed=42)
-    t_parallel = time.perf_counter() - start
+    elapsed = time.perf_counter() - start
 
     return OrderedDict(
         [
-            ("Parallel Pi (100k samples)", f"{t_parallel:.4f}s"),
-            ("CPU Cores Saturated", str(multiprocessing.cpu_count())),
+            ("Pi (100k samples)", f"{elapsed:.4f}s"),
+            ("Sampling mode", "single in-process random.Random stream"),
             ("Estimate error vs π", f"{abs(result.estimate - math.pi):.5f}"),
         ]
     )

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.5}/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.5",
   "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.5}/docs/benchmarks.md

@@ -59,7 +59,9 @@ number from this page.**
   of why O(1) sampling is the right design, not as a benchmark result.
 - **"CPU Cores Saturated" is a core count, not a saturation measurement.** It
   reports `multiprocessing.cpu_count()`. Nothing here verifies that every core
-  stayed busy or that the workload actually scaled.
+  stayed busy or that the workload actually scaled. The Monte Carlo table no
+  longer carries that row: `estimate_pi` samples on one in-process stream, so
+  a core count would be meaningless there.
 - **The generated section headers describe algorithms, not outcomes.** Strings
   like "Algorithmic Intelligence", "Approaching C-Speed" and "Hardware
   Saturation" come from the generator, not from the data. The first table's
@@ -109,10 +111,22 @@ This report measures both raw speed and algorithmic scaling. Pure Python is slow
 
 | Metric | Value |
 |--------|-------|
-| Parallel Pi (100k samples) | 0.0388s |
-| CPU Cores Saturated | 4 |
+| Pi (100k samples) | 0.0388s |
 | Estimate error vs π | 0.00791 |
 
+The timing above is the committed pre-change measurement and is kept
+unchanged rather than re-measured, because re-running the generator would
+overwrite the hand-written analysis on this page. `estimate_pi` no longer fans
+its samples out to a process pool: on the pooled path, Windows `spawn` cost
+≈1.4 s of interpreter start-up and module re-import per default call against
+≈0.014 s of actual sampling — about 100× the work it was meant to accelerate.
+The estimator now draws its whole sample from one `random.Random(seed)`
+stream in a single in-process pass, which also makes a *seeded* call
+machine-independent (the old chunk boundaries were derived from
+`cpu_count()`, so the result differed between hosts). The row the generator
+emits is now `Sampling mode | single in-process random.Random stream` in
+place of `CPU Cores Saturated`.
+
 #### Quantum sampling (estimated)
 
 | Metric | Value |

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.5}/docs/getting-started.md

@@ -69,6 +69,28 @@ cds hypothesis "what causes the Hubble tension?" --domain cosmology
 cds modules
 ```
 
+#### Exit codes
+
+`cds` exits with one of four documented statuses. They are named constants in
+`cds.cli._exit_codes`, re-exported from `cds.cli`, so a wrapper can compare
+statuses instead of comparing against bare integers.
+
+| Code | Name | Meaning |
+|------|------|---------|
+| `0` | `EXIT_OK` | The command completed and produced its output. Also returned by `--help`. |
+| `1` | `EXIT_ERROR` | The command was understood but could not be carried out: malformed values, an out-of-domain parameter, or a missing local resource such as the dashboard script. |
+| `2` | `EXIT_USAGE` | The command line was rejected by `argparse` — an unknown subcommand, a missing required argument, a bad `choices=` value, an unparseable number. (This is `argparse`'s own usage-error code.) |
+| `3` | `EXIT_MISSING_DEPENDENCY` | The command needs an optional extra that is not installed: `[plot]`/matplotlib for `plot --file`, `streamlit` for `dashboard`. The remedy is an install, not a corrected invocation. |
+
+```python
+from cds.cli import EXIT_ERROR, EXIT_MISSING_DEPENDENCY, describe, main
+
+describe(1)  # 'command was understood but could not be carried out'
+main(["stats", "1,x,3"])  # 1  — bad values
+main(["sample", "no-such-dist"])  # 2  — argparse rejected it
+main(["dashboard"])  # 3  — streamlit absent
+```
+
 ### Python API
 
 ```python

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.5}/docs/index.md

@@ -135,6 +135,25 @@ public feature modules. This table summarises them and the
 | `cds.nlp` | Educational NLP from scratch (BPE, embeddings, attention, MiniGPT) |
 | `cds.cli` | The `cds` console script (pure-stdlib `argparse`) |
 
+## Import behaviour
+
+Every module in the table is reachable as `cds.<name>`:
+
+```python
+import cds
+
+cds.pde  # attribute access works
+cds.interpolate  # so does this
+from cds.pde import solve_heat  # and the direct import
+```
+
+`cds.pde` and `cds.interpolate` are **lazily** imported by the package root
+(PEP 562 module `__getattr__`). Accessing `cds.pde` imports the subpackage on
+first touch and caches it, so `cds.pde` and `import cds.pde` yield the very
+same module object while never putting a PDE solver on the import path of code
+that does not use one. Everything else in the table is imported eagerly by
+`cds/__init__.py`.
+
 ## Quick Navigation
 
 - [Getting Started](getting-started.md)

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.5}/docs/tour_of_numerical_methods.md

@@ -64,7 +64,7 @@ n= 10,000  π≈3.1372  err=-4.39e-03  σ=1.65e-02
 n=100,000  π≈3.1292  err=-1.24e-02  σ=5.22e-03
 ```
 
-**The lesson.** Halving the standard error takes a **4×** larger sample, slow convergence. But notice the *standard error* tracks the actual error, and crucially the same recipe works in 100 dimensions where grid rules would need $100^{N}$ points. Monte Carlo trades speed for **generality**. CDS also parallelizes the sampling across CPU cores ([`montecarlo/methods.py`](https://github.com/Furox-Art/scientific-computing-system/blob/main/src/cds/montecarlo/methods.py)).
+**The lesson.** Halving the standard error takes a **4×** larger sample, slow convergence. But notice the *standard error* tracks the actual error, and crucially the same recipe works in 100 dimensions where grid rules would need $100^{N}$ points. Monte Carlo trades speed for **generality**. `estimate_pi` draws its whole sample from one `random.Random(seed)` stream in a single in-process pass ([`montecarlo/methods.py`](https://github.com/Furox-Art/scientific-computing-system/blob/main/src/cds/montecarlo/methods.py)), so a seeded call returns the same number on every machine and core count instead of a pool-schedule-dependent one.
 
 ---
 

{scientific_computing_system-2.2.3 → scientific_computing_system-2.2.5}/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.5}/package.json

@@ -1,6 +1,6 @@
 {
   "name": "scientific-computing-system",
-  "version": "2.2.3",
+  "version": "2.2.5",
   "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.5}/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.5"
 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"