messagefoundry 0.2.3__tar.gz → 0.2.5__tar.gz

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/.github/workflows/ci.yml

@@ -10,6 +10,11 @@ concurrency:
   group: ci-${{ github.ref }}
   cancel-in-progress: true
 
+# Least privilege: every job here only reads the repo and runs tests/builds (no gh writes, no git push,
+# no secrets), so a read-only default token is sufficient. A job needing more declares its own block.
+permissions:
+  contents: read
+
 jobs:
   # Lint + type-check + unit tests. The project supports a single Python — 3.14 — so every leg runs it.
   # Linux carries the cheap breadth (1x minutes); Windows Server 2022 + 2025 is the primary deployment
@@ -809,9 +814,13 @@ jobs:
         if: >-
           contains(needs.*.result, 'failure') ||
           contains(needs.*.result, 'cancelled')
+        env:
+          # Pass the needs context via env, not inline ${{ }} in the run block (defense-in-depth against
+          # template injection — a job output could in theory carry a quote that breaks out of echo).
+          NEEDS_JSON: ${{ toJSON(needs) }}
         run: |
           echo "::error::A gated CI leg failed or was cancelled."
-          echo '${{ toJSON(needs) }}'
+          echo "$NEEDS_JSON"
           exit 1
 
       - name: Gated legs OK

messagefoundry-0.2.5/.github/workflows/codeql.yml

@@ -0,0 +1,67 @@
+name: CodeQL
+
+# Deep semantic SAST (taint / data-flow analysis) that complements bandit and the curated semgrep
+# rules in security.yml — it finds vulnerable flows those pattern matchers can't, e.g. untrusted
+# HL7/config data reaching a sink across function boundaries.
+#
+# WHY THIS IS GUARDED TO THE MIRROR: CodeQL uploads results to GitHub code scanning, which on a
+# PRIVATE repo requires paid GitHub Advanced Security (see security.yml's header note). This repo's
+# source of truth is private, but the OSS mirror MEFORORG/MessageFoundry is PUBLIC, where CodeQL +
+# code scanning are FREE. So the analyze job is gated on the repo slug: it is SKIPPED (a no-op) on the
+# private source repo and runs only once publish.ps1 mirrors this file to MEFORORG/MessageFoundry.
+# Nothing to pay, nothing to fail on the private side.
+#
+# PINNING CAVEAT: this repo SHA-pins every Action for supply-chain integrity. actions/checkout below
+# reuses the repo's existing v7.0.0 pin; the github/codeql-action steps are on the v3 tag for now
+# because the live commit SHA must be looked up at authoring — SHA-pin them before treating this as a
+# hardened gate (OSSF Scorecard / zizmor would flag the unpinned tags).
+#
+# ALTERNATIVE (no file): on the public mirror you can instead enable CodeQL "default setup" from
+# Settings -> Security -> Code scanning (one toggle, auto-pinned, auto-updated). Default setup and this
+# advanced workflow are mutually exclusive — if you turn default setup ON, delete this file.
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+  schedule:
+    # Weekly, so newly-shipped CodeQL queries run against unchanged code (same rationale as the daily
+    # pip-audit cron: a fresh finding against a quiet codebase shouldn't wait for the next push).
+    - cron: "0 7 * * 1"
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  analyze:
+    name: CodeQL (${{ matrix.language }})
+    # ONLY on the public mirror — code scanning is free there; on the private source repo it would need
+    # paid GHAS, so this is a skipped no-op there. (GitHub Actions string == is case-insensitive.)
+    if: github.repository == 'MEFORORG/MessageFoundry'
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      security-events: write # upload the SARIF results to code scanning
+      actions: read
+    strategy:
+      fail-fast: false
+      matrix:
+        # python = the engine; javascript-typescript = the ide/ VS Code extension (both ship to the
+        # mirror). Both are interpreted — CodeQL needs no build step. Drop a language to narrow scope.
+        language: [python, javascript-typescript]
+    steps:
+      - name: Checkout
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false # CodeQL uploads via the job token, not a persisted git credential
+      - name: Initialize CodeQL
+        uses: github/codeql-action/init@dd903d2e4f5405488e5ef1422510ee31c8b32357 # v3.36.2
+        with:
+          languages: ${{ matrix.language }}
+          # security-extended adds higher-recall security queries on top of the default suite.
+          queries: security-extended
+      - name: Analyze
+        uses: github/codeql-action/analyze@dd903d2e4f5405488e5ef1422510ee31c8b32357 # v3.36.2
+        with:
+          category: "/language:${{ matrix.language }}"

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/.github/workflows/dependabot-lock-resync.yml

@@ -75,6 +75,10 @@ jobs:
           uv export --no-emit-project --no-dev --extra sqlserver --format requirements.txt -o docker/locks/requirements-sqlserver.lock
 
       - name: Commit and push the resynced locks
+        env:
+          # Pass the PR head ref through the environment, NOT inline ${{ }} in the run block, so a branch
+          # name containing shell metacharacters can never be evaluated as code (template injection).
+          HEAD_REF: ${{ github.event.pull_request.head.ref }}
         run: |
           set -euo pipefail
           git config user.name 'dependabot[bot]'
@@ -88,4 +92,4 @@ jobs:
           # Push with the persisted App-token credential (NOT GITHUB_TOKEN). An App-token push emits a
           # synchronize event so the required checks (DEP-1, ci.yml) re-run on the new commit; a
           # GITHUB_TOKEN push would leave them pending and the PR unmergeable.
-          git push origin "HEAD:${{ github.event.pull_request.head.ref }}"
+          git push origin "HEAD:${HEAD_REF}"

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/.github/workflows/release.yml

@@ -15,6 +15,14 @@
 # `-*` tags publish to PRODUCTION PyPI (a TestPyPI route would need its own Trusted Publisher). Cut the tag
 # only AFTER the py.typed marker (WS-3) is on main — the wheel smoke step enforces this on a tag.
 #
+# SECOND distribution — `messagefoundry-harness` (the synthetic test/load/failover harness,
+# packaging/messagefoundry-harness/) — is built + published in lockstep by the `release-harness` job
+# below (same version, same tag). Its PyPI publish is GATED on the `PUBLISH_HARNESS` repo variable so it
+# stays a no-op until the OWNER (one-time): (1) configures a `messagefoundry-harness` PyPI Trusted
+# Publisher — a PENDING publisher for repo wshallwshall/MessageFoundry + workflow `release.yml` (blank
+# environment, matching the engine) — then (2) sets repo variable PUBLISH_HARNESS=true. Until then the
+# job still BUILDS + version-checks the harness wheel each release and attaches it to the GitHub release.
+#
 # The version is single-sourced from messagefoundry/__init__.py (hatchling dynamic version), so the built
 # artifact's version must match the tag.
 name: release
@@ -26,16 +34,20 @@ on:
       - "v[0-9]+.[0-9]+.[0-9]+-*"  # pre-releases: v0.1.0-rc1, …
   workflow_dispatch:
 
-permissions:
-  contents: write       # create the release + upload its assets
-  id-token: write       # Sigstore signing, PyPI Trusted Publishing, + provenance — all via the GitHub OIDC identity
-  attestations: write   # write the SLSA build-provenance attestation (actions/attest-build-provenance)
+# Deny-all at the workflow level; each job below requests only the scopes it uses (least privilege).
+permissions: {}
 
 jobs:
   release:
     runs-on: ubuntu-latest
+    permissions:
+      contents: write       # create the release + upload its assets
+      id-token: write       # Sigstore signing, PyPI Trusted Publishing, + provenance — all via the GitHub OIDC identity
+      attestations: write   # write the SLSA build-provenance attestation (actions/attest-build-provenance)
     steps:
       - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false  # release uses GH_TOKEN env / OIDC, never the persisted git credential
 
       - name: Set up Python
         uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6
@@ -151,3 +163,69 @@ jobs:
           packages-dir: dist-pub/
           skip-existing: true
           attestations: true
+
+  release-harness:
+    # Build + publish the SEPARATE `messagefoundry-harness` distribution (the synthetic test/load/failover
+    # harness, packaging/messagefoundry-harness/) in lockstep with the engine — same version, same tag.
+    # Isolated from the `release` job so a harness-side issue can never jeopardize the engine release;
+    # `needs: release` so the engine ships (and its GitHub release exists) first. Inherits the workflow's
+    # contents:write + id-token:write. The PyPI publish is GATED on the `PUBLISH_HARNESS` repo variable:
+    # until the owner sets up the harness Trusted Publisher AND PUBLISH_HARNESS=true (see the header note),
+    # this job still BUILDS + version-checks the wheel and attaches it to the GitHub release, but does not
+    # publish — so a missing harness PyPI project can never red a release.
+    needs: release
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write   # gh release upload (attach the harness wheel)
+      id-token: write   # PyPI Trusted Publishing (OIDC) for the harness wheel
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false  # gh upload uses GH_TOKEN env / OIDC, never the persisted git credential
+
+      - name: Set up Python
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6
+        with:
+          python-version: "3.14"
+
+      - name: Build the harness wheel (wheel-only — harness/ is force-included from the repo root)
+        run: |
+          python -m pip install --upgrade pip build
+          # Wheel-only on purpose: the harness source (harness/) lives OUTSIDE this project dir (it is
+          # force-included from ../../harness), so an sdist would not be self-contained. Pure-Python, so a
+          # wheel suffices. Version is read from messagefoundry/__init__.py (lockstep with the engine).
+          python -m build --wheel ./packaging/messagefoundry-harness --outdir harness-dist
+          ls -l harness-dist/
+
+      - name: Smoke-check the harness wheel (version == engine == tag)
+        run: |
+          built=$(python -c "import glob,re; print(re.search(r'messagefoundry_harness-([^-]+)-', glob.glob('harness-dist/*.whl')[0]).group(1))")
+          echo "harness wheel version: $built"
+          if [ "${GITHUB_REF_TYPE:-}" = "tag" ]; then
+            want="${GITHUB_REF_NAME#v}"
+            [ "$built" = "$want" ] || { echo "::error::harness wheel version $built != tag $want"; exit 1; }
+          fi
+
+      - name: Attach the harness wheel to the GitHub release
+        if: startsWith(github.ref, 'refs/tags/')
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: gh release upload "${GITHUB_REF_NAME}" harness-dist/*.whl --clobber
+
+      - name: Upload harness artifact (dry-run / always)
+        if: always()
+        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
+        with:
+          name: harness-artifacts
+          path: harness-dist/
+          if-no-files-found: ignore
+
+      # GATED: no-op until the owner configures the messagefoundry-harness PyPI Trusted Publisher AND sets
+      # repo variable PUBLISH_HARNESS=true. The build + version-check above still run every release.
+      - name: Publish messagefoundry-harness to PyPI (Trusted Publishing / OIDC)
+        if: ${{ startsWith(github.ref, 'refs/tags/') && vars.PUBLISH_HARNESS == 'true' }}
+        uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0
+        with:
+          packages-dir: harness-dist/
+          skip-existing: true
+          attestations: true

messagefoundry-0.2.5/.github/workflows/scorecard.yml

@@ -0,0 +1,59 @@
+name: Scorecard
+
+# OpenSSF Scorecard — a holistic supply-chain hygiene score (Pinned-Dependencies, Dangerous-Workflow,
+# Token-Permissions, Branch-Protection, Maintained, SAST-present, ...). It validates the hardening this
+# repo already does (SHA-pinned Actions, least-privilege tokens) and catches regressions, and yields a
+# public OpenSSF badge.
+#
+# WHY GUARDED TO THE MIRROR: like CodeQL, Scorecard uploads SARIF to GitHub code scanning (paid GHAS on
+# a private repo) and `publish_results: true` requires a PUBLIC repo. So this is gated to the public
+# mirror MEFORORG/MessageFoundry — a skipped no-op on the private source repo, free on the mirror after
+# publish.ps1 mirrors this file. NOTE: the Branch-Protection check then reflects the MIRROR's settings,
+# not the private repo's; the workflow-hardening checks (Pinned-Dependencies / Dangerous-Workflow /
+# Token-Permissions) assess the shared source and are the signal that transfers.
+#
+# PINNING CAVEAT: actions/checkout + actions/upload-artifact reuse this repo's existing SHA pins; the
+# ossf/scorecard-action and github/codeql-action/upload-sarif steps are on version tags pending a
+# SHA-pin lookup (zizmor / Scorecard itself will flag them).
+on:
+  branch_protection_rule:
+  schedule:
+    - cron: "0 8 * * 1" # weekly (Mon 08:00 UTC)
+  push:
+    branches: [main]
+  workflow_dispatch:
+
+permissions: read-all
+
+jobs:
+  analysis:
+    name: Scorecard analysis
+    # ONLY on the public mirror (free code scanning + public badge); skipped no-op on the private repo.
+    if: github.repository == 'MEFORORG/MessageFoundry'
+    runs-on: ubuntu-latest
+    permissions:
+      security-events: write # upload the SARIF results to code scanning
+      id-token: write # publish results to the public OpenSSF Scorecard API (the badge)
+      contents: read
+      actions: read
+    steps:
+      - name: Checkout
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          persist-credentials: false
+      - name: Run Scorecard
+        uses: ossf/scorecard-action@4eaacf0543bb3f2c246792bd56e8cdeffafb205a # v2.4.3
+        with:
+          results_file: results.sarif
+          results_format: sarif
+          publish_results: true
+      - name: Upload the SARIF artifact
+        uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7
+        with:
+          name: scorecard-sarif
+          path: results.sarif
+          retention-days: 5
+      - name: Upload to code scanning
+        uses: github/codeql-action/upload-sarif@dd903d2e4f5405488e5ef1422510ee31c8b32357 # v3.36.2
+        with:
+          sarif_file: results.sarif

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/.github/workflows/security.yml

@@ -109,6 +109,43 @@ jobs:
           name: sbom-cyclonedx
           path: sbom.cdx.json
 
+  trivy:
+    name: trivy (container image vulnerabilities)
+    runs-on: ubuntu-latest
+    # ADVISORY for its first cycle (continue-on-error): scan the built engine image for OS-package and
+    # Python CVEs — the supply-chain layer pip-audit (lockfile only) and bandit/semgrep (source only)
+    # never see: the Debian base, system libs, and (on the -sqlserver variant) the msodbcsql18/unixODBC
+    # apt layer. Once a baseline run confirms it's clean, DELETE `continue-on-error` to make it BLOCKING
+    # like the other gates here. There's now a real docker/Dockerfile, so the image is a live surface.
+    continue-on-error: true
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+      - name: Build the slim engine image
+        # The slim default the docker-smoke leg (ci.yml) and the Dockerfile's `docker build` docs produce.
+        run: docker build -f docker/Dockerfile -t messagefoundry:scan .
+      - name: Install Trivy (pinned)
+        run: |
+          # Pin the release; bump deliberately (same posture as the gitleaks job). Verify the tag exists
+          # at https://github.com/aquasecurity/trivy/releases if this step 404s.
+          VER=0.71.2
+          curl -sSfL "https://github.com/aquasecurity/trivy/releases/download/v${VER}/trivy_${VER}_Linux-64bit.tar.gz" \
+            | tar -xz -C /tmp trivy
+          sudo install -m 0755 /tmp/trivy /usr/local/bin/trivy
+          trivy --version
+      - name: Scan the image (fixable HIGH/CRITICAL fail the build)
+        # --ignore-unfixed keeps the gate ACTIONABLE: a Debian CVE with no upstream fix can't be
+        # remediated by us and shouldn't redden CI; only patchable HIGH/CRITICAL fail. --scanners vuln
+        # keeps this to CVEs (secrets stay gitleaks' job). Extend to `--target runtime-sqlserver` (more
+        # OS surface) once this is green. Trivy auto-pulls its vuln DB from ghcr.io on first run.
+        run: |
+          trivy image --no-progress --scanners vuln \
+            --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 \
+            messagefoundry:scan
+      - name: Lint the Dockerfile for misconfig (informational)
+        # IaC checks (non-root USER, pinned base, secrets in layers). Informational only — never fails.
+        if: always()
+        run: trivy config --no-progress --severity HIGH,CRITICAL docker/Dockerfile || true
+
   bandit:
     name: bandit (Python SAST)
     runs-on: ubuntu-latest
@@ -174,6 +211,32 @@ jobs:
           # dangerous-sink rules as the engine.
           semgrep --config .semgrep --error --metrics off messagefoundry tee
 
+  zizmor:
+    name: zizmor (GitHub Actions static analysis)
+    runs-on: ubuntu-latest
+    # BLOCKING: static analysis of the workflow files THEMSELVES (Trail of Bits) — template injection,
+    # over-broad GITHUB_TOKEN permissions, dangerous triggers, artifact-credential persistence. The
+    # baseline is clean — high-confidence findings are fixed in-tree (least-privilege per-job permissions,
+    # env-passed refs, persist-credentials: false) and the few safe-by-design ones are recorded with a
+    # justification in .github/zizmor.yml — so a NEW workflow-security regression now fails the build.
+    # Tune suppressions in .github/zizmor.yml (with a reason), not by relaxing this gate.
+    permissions:
+      contents: read
+    steps:
+      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6
+        with:
+          python-version: "3.14"
+      - name: Install zizmor (pinned)
+        run: |
+          # Pin deliberately; verify the tag at https://github.com/zizmorcore/zizmor/releases if it 404s.
+          python -m pip install --upgrade pip "zizmor==1.5.2"
+      - name: Analyze the workflows
+        env:
+          # Lets zizmor run its online audits (e.g. unpinned / known-problematic action refs).
+          GH_TOKEN: ${{ github.token }}
+        run: zizmor .github/workflows
+
   crypto-inventory:
     name: crypto-inventory (ASVS 11.1.3 discovery gate)
     runs-on: ubuntu-latest

messagefoundry-0.2.5/.github/zizmor.yml

@@ -0,0 +1,31 @@
+# zizmor configuration — https://docs.zizmor.sh/configuration/
+#
+# Each entry below is a REVIEWED, justified non-finding for this repo. Real fixes live in the workflow
+# files themselves (least-privilege permissions, env-passed refs, persist-credentials: false); this file
+# is only for findings that are safe-by-design here. Keep it small and commented — a suppression without
+# a reason is a latent vulnerability.
+rules:
+  dangerous-triggers:
+    ignore:
+      # A CLA assistant REQUIRES pull_request_target to record signatures + comment on fork PRs. This
+      # workflow never checks out untrusted PR code, pins the third-party action by SHA, and gates on the
+      # immutable comment body / event name — so the usual pull_request_target risk (running attacker
+      # code with a write token) does not apply. See the SECURITY note in cla.yml.
+      - cla.yml
+
+  artipacked:
+    ignore:
+      # artipacked flags a checkout that persists the token's git credential — a risk only if that
+      # credential can leak into an uploaded artifact. The jobs below do not push and never upload the
+      # repo/.git tree, so the persisted credential is inert noise here.
+      #
+      # NOT suppressed (fixed at the source instead): release.yml sets persist-credentials: false on both
+      # checkouts because it DOES upload build artifacts. dependabot-lock-resync.yml persists a
+      # narrowly-scoped App token ON PURPOSE to push the resynced locks (documented inline) and is listed
+      # here for that reason.
+      - benchmark.yml
+      - ci.yml
+      - dependabot-lock-resync.yml
+      - release-sync-check.yml
+      - security.yml
+      - vuln-metrics.yml

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/CHANGELOG.md

@@ -6,6 +6,38 @@ All notable changes to MessageFoundry are documented here. The format follows
 
 ## [Unreleased]
 
+## [0.2.5] — 2026-06-26 — Early Access
+
+A bug-fix release hardening SQL Server cluster cold-start.
+
+### Fixed
+- **SQL Server: concurrent schema-init race on a virgin DB (HA cold start).** Two cluster nodes starting
+  simultaneously against an empty database both ran the `IF OBJECT_ID(...) IS NULL CREATE TABLE` guards
+  with no cross-node lock, so both issued `CREATE` and the loser died at startup on a `2714` ("There is
+  already an object named ..."). `_ensure_schema` now takes an exclusive `sp_getapplock`
+  (`mefor:schema_init`) around the DDL — the T-SQL analog of the PostgreSQL store's existing schema
+  advisory lock — so the second node serializes and runs the now-no-op guarded CREATEs cleanly. Single-node
+  and pre-created schema are unaffected; SQLite and PostgreSQL were already race-safe. (#553)
+
+### Changed
+- Docs: the `[cluster]` settings docstring and the pool-size validation error now name both `postgres` and
+  `sqlserver` (the cross-section validator already admitted both). (#553)
+
+## [0.2.4] — 2026-06-26 — Early Access
+
+A bug-fix release that completes the EF-6 SQL Server fix shipped in 0.2.3.
+
+### Fixed
+- **SQL Server: EF-6 "Connection is busy with results for another command" fully resolved (0.2.3's fix
+  was incomplete).** v0.2.3 (#543) switched the FIFO claim read to `fetchall`, but draining the
+  `UPDATE...OUTPUT` *rows* does not free the *statement handle* — without MARS the pooled connection was
+  still returned to the aioodbc pool busy, so the error reproduced at every cold start. All pooled cursor
+  sites now close the cursor (`SQLFreeStmt`/`SQLCloseCursor`) via a new `_cursor` context manager before
+  the connection is released, on both the success and exception paths; `claim_ready` (another
+  `UPDATE...OUTPUT`) and the `DELETE...OUTPUT` handoffs had the same latent gap and are covered too. A
+  driver-free unit test now asserts the close-before-release invariant so the regression can't recur.
+  SQLite and PostgreSQL were unaffected. (#550)
+
 ## [0.2.3] — 2026-06-26 — Early Access
 
 A bug-fix + feature release: the SQL Server store no longer raises "connection busy" errors under
@@ -171,7 +203,9 @@ tests, but the external code review + penetration test (the bar for a security-c
 - Releases are built, SBOM'd (CycloneDX), and signed with [Sigstore](https://www.sigstore.dev/) — see the
   `release` workflow.
 
-[Unreleased]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.3...HEAD
+[Unreleased]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.5...HEAD
+[0.2.5]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.4...v0.2.5
+[0.2.4]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.3...v0.2.4
 [0.2.3]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.2...v0.2.3
 [0.2.2]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.1...v0.2.2
 [0.2.1]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.0...v0.2.1

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/PKG-INFO

@@ -1,10 +1,23 @@
 Metadata-Version: 2.4
 Name: messagefoundry
-Version: 0.2.3
+Version: 0.2.5
 Summary: Open-source healthcare integration engine — route, transform, and validate messages across many formats and connection types
 License-Expression: AGPL-3.0-or-later
 License-File: LICENSE
 License-File: NOTICE
+Classifier: Development Status :: 4 - Beta
+Classifier: Environment :: Console
+Classifier: Intended Audience :: Developers
+Classifier: Intended Audience :: Healthcare Industry
+Classifier: Intended Audience :: System Administrators
+Classifier: Operating System :: Microsoft :: Windows
+Classifier: Operating System :: POSIX :: Linux
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Communications
+Classifier: Topic :: Software Development :: Libraries :: Application Frameworks
+Classifier: Topic :: System :: Networking
+Classifier: Typing :: Typed
 Requires-Python: >=3.14
 Requires-Dist: aiosqlite>=0.20
 Requires-Dist: argon2-cffi>=23.1
@@ -151,13 +164,20 @@ deliberate — replace `<version>` with the current release shown at the top of
 needs (each is opt-in and lazy-imported):
 
 ```bash
+pip install "messagefoundry[console]==<version>"     # admin console (PySide6 GUI) — the operator UI; most operators want this
 pip install "messagefoundry[postgres]==<version>"    # PostgreSQL store backend (production server DB)
 pip install "messagefoundry[sqlserver]==<version>"   # SQL Server store backend (+ OS-level ODBC Driver 18)
-pip install "messagefoundry[console]==<version>"     # PySide6 admin console
 pip install "messagefoundry[sftp]==<version>"        # SFTP transport for the REMOTEFILE connector
 pip install "messagefoundry[dicom]==<version>"       # DICOM codec + C-STORE SCP (pydicom + pynetdicom)
 ```
 
+**What's in the `messagefoundry` package — and what isn't.** It is the **engine plus the admin
+console**: the console ships in the same wheel, with its PySide6/GUI dependencies as the opt-in
+`[console]` extra, so a headless server, container, or adopter install stays lean — the console is one
+flag away (`messagefoundry[console]`) when you want the operator UI. The **VS Code extension is a
+separate product, not on PyPI** (a VS Code extension is a different ecosystem); see *VS Code extension &
+test harness* below for where to get it.
+
 > **Verify before you install (supply chain).** Every release is built by a GitHub Actions workflow,
 > Sigstore-signed, and carries SLSA build-provenance + PEP 740 attestations. Verify a downloaded
 > wheel against its source commit with
@@ -201,10 +221,16 @@ python -m messagefoundry.console --url http://127.0.0.1:8765
 
 - **VS Code extension** ([`ide/`](https://github.com/wshallwshall/MessageFoundry/tree/main/ide/)) — author and test interfaces in your editor: a New Route
   Wizard, validate-on-save, a Test Bench (dry-run `.hl7` files with before/after diffs), Stage →
-  Promote to a running engine, and an HL7-aware `@messagefoundry` chat participant. Open the `ide/`
-  folder in VS Code and press **F5**, or see [ide/README.md](https://github.com/wshallwshall/MessageFoundry/blob/main/ide/README.md).
-- **Test harness** — a standalone PySide6 send/receive MLLP tool for exercising the engine with
-  synthetic, PHI-free traffic: `python -m harness`.
+  Promote to a running engine, and an HL7-aware `@messagefoundry` chat participant. **It is not on PyPI**
+  (a VS Code extension is a different ecosystem) **and not yet on the VS Code Marketplace** — Marketplace
+  + Open VSX publishing is **planned** (see [the backlog](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/BACKLOG.md)). Until then, get it from
+  this repo: open the `ide/` folder in VS Code and press **F5** (Extension Development Host), or build the
+  VSIX (`cd ide && npm install && npx @vscode/vsce package`) and install the `.vsix`. See
+  [ide/README.md](https://github.com/wshallwshall/MessageFoundry/blob/main/ide/README.md).
+- **Test harness** — synthetic-only send/receive (MLLP), load, and failover tooling for exercising a
+  running engine. It ships as a **separate distribution, `messagefoundry-harness`**, released in lockstep
+  with the engine (it is *not* in the engine wheel): `pip install messagefoundry-harness`, then
+  `python -m harness`. From a checkout, run `python -m harness` directly. Synthetic, PHI-free traffic only.
 
 ## License
 

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/README.md

@@ -98,13 +98,20 @@ deliberate — replace `<version>` with the current release shown at the top of
 needs (each is opt-in and lazy-imported):
 
 ```bash
+pip install "messagefoundry[console]==<version>"     # admin console (PySide6 GUI) — the operator UI; most operators want this
 pip install "messagefoundry[postgres]==<version>"    # PostgreSQL store backend (production server DB)
 pip install "messagefoundry[sqlserver]==<version>"   # SQL Server store backend (+ OS-level ODBC Driver 18)
-pip install "messagefoundry[console]==<version>"     # PySide6 admin console
 pip install "messagefoundry[sftp]==<version>"        # SFTP transport for the REMOTEFILE connector
 pip install "messagefoundry[dicom]==<version>"       # DICOM codec + C-STORE SCP (pydicom + pynetdicom)
 ```
 
+**What's in the `messagefoundry` package — and what isn't.** It is the **engine plus the admin
+console**: the console ships in the same wheel, with its PySide6/GUI dependencies as the opt-in
+`[console]` extra, so a headless server, container, or adopter install stays lean — the console is one
+flag away (`messagefoundry[console]`) when you want the operator UI. The **VS Code extension is a
+separate product, not on PyPI** (a VS Code extension is a different ecosystem); see *VS Code extension &
+test harness* below for where to get it.
+
 > **Verify before you install (supply chain).** Every release is built by a GitHub Actions workflow,
 > Sigstore-signed, and carries SLSA build-provenance + PEP 740 attestations. Verify a downloaded
 > wheel against its source commit with
@@ -148,10 +155,16 @@ python -m messagefoundry.console --url http://127.0.0.1:8765
 
 - **VS Code extension** ([`ide/`](https://github.com/wshallwshall/MessageFoundry/tree/main/ide/)) — author and test interfaces in your editor: a New Route
   Wizard, validate-on-save, a Test Bench (dry-run `.hl7` files with before/after diffs), Stage →
-  Promote to a running engine, and an HL7-aware `@messagefoundry` chat participant. Open the `ide/`
-  folder in VS Code and press **F5**, or see [ide/README.md](https://github.com/wshallwshall/MessageFoundry/blob/main/ide/README.md).
-- **Test harness** — a standalone PySide6 send/receive MLLP tool for exercising the engine with
-  synthetic, PHI-free traffic: `python -m harness`.
+  Promote to a running engine, and an HL7-aware `@messagefoundry` chat participant. **It is not on PyPI**
+  (a VS Code extension is a different ecosystem) **and not yet on the VS Code Marketplace** — Marketplace
+  + Open VSX publishing is **planned** (see [the backlog](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/BACKLOG.md)). Until then, get it from
+  this repo: open the `ide/` folder in VS Code and press **F5** (Extension Development Host), or build the
+  VSIX (`cd ide && npm install && npx @vscode/vsce package`) and install the `.vsix`. See
+  [ide/README.md](https://github.com/wshallwshall/MessageFoundry/blob/main/ide/README.md).
+- **Test harness** — synthetic-only send/receive (MLLP), load, and failover tooling for exercising a
+  running engine. It ships as a **separate distribution, `messagefoundry-harness`**, released in lockstep
+  with the engine (it is *not* in the engine wheel): `pip install messagefoundry-harness`, then
+  `python -m harness`. From a checkout, run `python -m harness` directly. Synthetic, PHI-free traffic only.
 
 ## License
 

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/docs/BACKLOG.md

@@ -104,6 +104,7 @@ separate owner exercise** — this is the candidate set, not a committed plan.
 | **#27 Serial / ASTM** | Low | **confirm-decline** | S | Out-of-scope niche, no demand (recorded #411). Revisit only on a concrete lab-analyzer requirement. |
 | **ASVS 13.3.3 HSM/KMS/Vault KeyProvider** | Med | **done** | — | #377 merged (`d35dbde`). Prune the stale `asvs-1333-keyprovider` worktree — don't fund twice. |
 | **ASVS 4.1.5 per-message signing** | Med | **done** | — | #378 merged (`9c00b88`). Prune the stale `asvs-415-msg-signing` worktree. |
+| **Publish the VS Code extension (Marketplace + Open VSX)** | Med | do-next | M | Publish the `ide/` extension to the **VS Code Marketplace** + **Open VSX** (`.vsix` via `vsce`/`ovsx`) so users install it instead of F5-from-source; add a CI publish leg + publisher accounts. **Owner: do soon, AFTER the planned IDE-focused improvements land** (not now — recorded 2026-06-26). Not a PyPI artifact (different ecosystem). |
 
 **Top strategic calls:**
 1. **Lock v0.2 now** on fresh #28/#29 evidence + a #22b ship-or-slip — the single highest-leverage release-close move.

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/messagefoundry/__init__.py

@@ -60,7 +60,7 @@ from messagefoundry.parsing.message import Message, RawMessage
 from messagefoundry.parsing.split import split_by_obr
 from messagefoundry.timezone import convert_hl7_timestamp, to_zone
 
-__version__ = "0.2.3"
+__version__ = "0.2.5"
 
 __all__ = [
     "Message",

{messagefoundry-0.2.3 → messagefoundry-0.2.5}/messagefoundry/config/settings.py

@@ -1116,8 +1116,8 @@ class ClusterSettings(_Section):
     ``heartbeat_seconds`` to ``DB_now + leader_lease_ttl_seconds``, a standby acquires only once that
     lease has expired, and a leader that cannot renew within ``leader_fence_timeout_seconds`` self-fences
     before the lease can expire (the split-brain guard). The cross-section validator below requires
-    ``[store].backend = postgres`` and ``[store].pool_size >= 2`` when this is enabled (a clustered node
-    drives concurrent background work against the pool)."""
+    ``[store].backend`` in ``{postgres, sqlserver}`` and ``[store].pool_size >= 2`` when this is enabled
+    (a clustered node drives concurrent background work against the pool)."""
 
     enabled: bool = False
     # Override the auto-generated node id (host:pid:hex). Pin it for a stable identity across restarts
@@ -1306,7 +1306,7 @@ class ServiceSettings(BaseModel):
                     f"(got {self.store.pool_size}); a clustered node drives concurrent background work "
                     "(the membership/lease maintenance loop + the leader reclaim sweep + the per-stage "
                     "workers) against the pool, so a pool of 1 would serialize everything — prefer "
-                    "pool_size >= 3 for clustered Postgres"
+                    "pool_size >= 3 for a clustered node (Postgres or SQL Server)"
                 )
         return self