messagefoundry 0.2.6__tar.gz → 0.2.8__tar.gz

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/.gitattributes

@@ -2,3 +2,4 @@
 # `git diff --exit-code`) can't be tripped by Windows CRLF drift (DEP-1).
 uv.lock text eol=lf
 requirements.lock text eol=lf
+.mefor-hooks/** text eol=lf

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/.github/workflows/release.yml

@@ -54,6 +54,21 @@ jobs:
         with:
           python-version: "3.14"
 
+      - name: Rewrite README repo slug for the public PyPI long_description
+        run: |
+          # PyPI renders README.md (pyproject `readme = "README.md"`) as the project description and
+          # fetches it anonymously. The source README points at the PRIVATE source repo
+          # (wshallwshall/MessageFoundry) so the team's GitHub view shows the private repo's own CI
+          # badges — but anonymous fetches of a private repo's Actions badge SVG 404 (broken badge
+          # images), and every body link 404s on click. The public mirror (MEFORORG/MessageFoundry)
+          # runs the same workflows and is anonymously reachable, so rewrite the slug here (the same
+          # rewrite scripts/publish/publish.ps1 applies to the mirror) before `python -m build` embeds
+          # the README. Ephemeral runner edit only — never committed.
+          sed -i 's#wshallwshall/MessageFoundry#MEFORORG/MessageFoundry#g' README.md
+          if grep -q 'wshallwshall/MessageFoundry' README.md; then
+            echo '::error::README slug rewrite left private-repo links'; exit 1
+          fi
+
       - name: Build sdist + wheel
         run: |
           python -m pip install --upgrade pip build

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/.gitignore

@@ -80,3 +80,8 @@ TRANSCRIPTS.md
 # Still usable by name (they sit in PROFILES_DIR) and copy-on to the test box.
 /harness/load/profiles/hospital-baseline.toml
 /harness/load/profiles/soak-12h.toml
+# --- MessageFoundry ---
+.mefor/
+*.db*
+.DS_Store
+Thumbs.db

messagefoundry-0.2.8/.mefor-hooks/pre-commit

@@ -0,0 +1,25 @@
+#!/bin/sh
+# MessageFoundry pre-commit checks — generated by the VS Code extension.
+# Runs `messagefoundry check` so a commit can't introduce a broken config.
+# Bypass once with: git commit --no-verify
+
+PY=python
+command -v python >/dev/null 2>&1 || PY=python3
+if ! command -v "$PY" >/dev/null 2>&1; then
+  echo "MessageFoundry: python not found; skipping checks." >&2
+  exit 0
+fi
+
+# Prefer a project virtualenv if present (Windows + POSIX layouts).
+if [ -x ".venv/Scripts/python.exe" ]; then
+  PY=".venv/Scripts/python.exe"
+elif [ -x ".venv/bin/python" ]; then
+  PY=".venv/bin/python"
+fi
+
+if ! "$PY" -c "import messagefoundry" >/dev/null 2>&1; then
+  echo "MessageFoundry: 'messagefoundry' not importable in this environment; skipping checks." >&2
+  exit 0
+fi
+
+exec "$PY" -m messagefoundry check --config 'samples/config' --messages 'samples/messages'

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/CHANGELOG.md

@@ -6,6 +6,70 @@ All notable changes to MessageFoundry are documented here. The format follows
 
 ## [Unreleased]
 
+## [0.2.8] — 2026-06-27 — Early Access
+
+A tooling/ops release: the load harness gains a **multi-shard driver** so one harness can drive a
+`supervise` cluster (unblocking the multi-core throughput measurement), `supervise` resolves
+`--env` files for its shards, and a prominent upgrade note for the config-directory permission
+guard introduced in 0.2.6.
+
+> ### ⚠ Upgrading from ≤ 0.2.5 — tighten config-dir ACLs first
+> The config-directory permission guard (SEC-003 / ADR 0036), added in **0.2.6**, refuses to load a
+> `--config` directory that is **writable by a broad principal** (e.g. `Authenticated Users` /
+> `S-1-5-11`). A deployment whose config dir inherits that write — common under `C:\srv\…` — will
+> **fail to start on first upgrade to ≥ 0.2.6** with *"refusing to load config from writable-by-others
+> path …"*. **Before upgrading**, tighten the directory (elevated):
+> ```powershell
+> icacls "<config-dir>" /inheritance:d /T
+> icacls "<config-dir>" /remove:g *S-1-5-11 /T          # drop Authenticated Users
+> icacls "<config-dir>" /grant *S-1-5-18:(OI)(CI)F /grant *S-1-5-32-544:(OI)(CI)F /T  # SYSTEM + Admins
+> ```
+> See [`docs/SERVICE.md`](docs/SERVICE.md) → *Update to a new build* and *Lock down the config
+> directory (CONFIG-2)*.
+
+### Added
+- **Multi-shard load driving (`messagefoundry-harness`).** `python -m harness` gains
+  **`--skip-preflight`** (drive shard MLLP ports that no single `--engine` owns) and a repeatable
+  **`--shard-engine <url>`**: the engine poller now takes a list of shard APIs and **sums** each
+  shard's `/stats` (read/written/backlog/in_pipeline/queue_depth/dead) into one cluster sample, so
+  the no-loss reconcile and drain are **cluster-aggregate** — a healthy K-shard run reports pass,
+  not a false "lost on intake". With no `--shard-engine` the behavior is byte-identical to before.
+  Two sample graphs ship for the throughput suite: `harness/config/store_once` (the
+  dedup-triggering one-handler-`list[Send]`-of-identical-body shape for store-once) and
+  `harness/config/passthrough` (an internal `PassThrough()` re-ingress hop); the load graph
+  (`harness/config/load`) is now shard-taggable via `MEFOR_LOAD_SHARD_ADT`/`_RESULTS`/`_OTHER`. (#604)
+
+### Fixed
+- **`supervise --project-root`.** `supervise` now accepts `--project-root` and forwards it to each
+  spawned `serve --shard`, so `supervise --config <dir> --env <env>` resolves each shard's
+  `environments/<env>.toml` (previously the shards resolved nothing from their spawned cwd and
+  required an explicit `--service-config` posture). Backward compatible — no `--project-root` is
+  unchanged. (#602)
+
+## [0.2.7] — 2026-06-27 — Early Access
+
+A docs/packaging release that fixes the broken badge images on the PyPI project page
+and adds a config-check pre-commit hook.
+
+### Fixed
+- **Broken badge images in the PyPI project description.** The CI and Security status
+  badges in the README pointed at the **private** source repo, so they rendered as
+  broken images on the public PyPI page — an anonymous viewer can't fetch a private
+  repo's GitHub Actions badge SVG (it 404s). The README now points at the public
+  mirror (`MEFORORG/MessageFoundry`), and the release build additionally rewrites any
+  remaining `wshallwshall`→`MEFORORG` repo slug in the README before it is embedded as
+  the PyPI `long_description`, so the rendered badges resolve anonymously. (#568)
+
+### Added
+- **`messagefoundry check` pre-commit hook.** A VS Code-extension-generated
+  `.mefor-hooks/pre-commit` runs `messagefoundry check` so a commit can't introduce a
+  broken config (skips cleanly if python or the package isn't importable; bypass with
+  `--no-verify`). (#568)
+
+### Docs
+- Backlog **#47** — base64 embedded-document (attachment) pruning (Mirth
+  attachment-handler / data-pruner parity); and a Changelog link in the README. (#568)
+
 ## [0.2.6] — 2026-06-27 — Early Access
 
 A large release: the **throughput-maximization build** (high-fan-out store-once, multi-process
@@ -275,7 +339,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.6...HEAD
+[Unreleased]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.8...HEAD
+[0.2.8]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.7...v0.2.8
+[0.2.7]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.6...v0.2.7
 [0.2.6]: https://github.com/wshallwshall/MessageFoundry/compare/v0.2.5...v0.2.6
 [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

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/PKG-INFO

@@ -1,7 +1,11 @@
 Metadata-Version: 2.4
 Name: messagefoundry
-Version: 0.2.6
+Version: 0.2.8
 Summary: Open-source healthcare integration engine — route, transform, and validate messages across many formats and connection types
+Project-URL: Homepage, https://messagefoundry.org/
+Project-URL: Documentation, https://messagefoundry.org/
+Project-URL: Repository, https://github.com/MEFORORG/MessageFoundry
+Project-URL: Issues, https://github.com/MEFORORG/MessageFoundry/issues
 License-Expression: AGPL-3.0-or-later
 License-File: LICENSE
 License-File: NOTICE
@@ -66,10 +70,13 @@ Description-Content-Type: text/markdown
 
 # MessageFoundry
 
-[![CI](https://github.com/wshallwshall/MessageFoundry/actions/workflows/ci.yml/badge.svg)](https://github.com/wshallwshall/MessageFoundry/actions/workflows/ci.yml)
-[![Security](https://github.com/wshallwshall/MessageFoundry/actions/workflows/security.yml/badge.svg)](https://github.com/wshallwshall/MessageFoundry/actions/workflows/security.yml)
-[![License: AGPL v3](https://img.shields.io/badge/License-AGPL_v3-blue.svg)](https://github.com/wshallwshall/MessageFoundry/blob/main/LICENSE)
-[![Python 3.14+](https://img.shields.io/badge/python-3.14%2B-blue.svg)](https://github.com/wshallwshall/MessageFoundry/blob/main/pyproject.toml)
+[![CI](https://github.com/MEFORORG/MessageFoundry/actions/workflows/ci.yml/badge.svg)](https://github.com/MEFORORG/MessageFoundry/actions/workflows/ci.yml)
+[![Security](https://github.com/MEFORORG/MessageFoundry/actions/workflows/security.yml/badge.svg)](https://github.com/MEFORORG/MessageFoundry/actions/workflows/security.yml)
+[![License: AGPL v3](https://img.shields.io/badge/License-AGPL_v3-blue.svg)](https://github.com/MEFORORG/MessageFoundry/blob/main/LICENSE)
+[![Python 3.14+](https://img.shields.io/badge/python-3.14%2B-blue.svg)](https://github.com/MEFORORG/MessageFoundry/blob/main/pyproject.toml)
+
+**Website & documentation: [messagefoundry.org](https://messagefoundry.org/)** ·
+**[Changelog](https://github.com/MEFORORG/MessageFoundry/blob/main/CHANGELOG.md)**
 
 MessageFoundry is an **open-source healthcare integration engine** — a modern, Python-native HL7
 interface engine. It connects clinical and business systems by routing, transforming, and validating
@@ -96,10 +103,10 @@ The PySide6 console talks to it over a localhost HTTP + WebSocket API — the sa
 whether the engine runs in-process, as a local daemon, or (later) on a remote host.
 No hand-rolled IPC; the deployment split is a config choice, not an architectural fork.
 
-See **[docs/architecture-diagram.md](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/architecture-diagram.md)** for the rendered diagrams —
+See **[docs/architecture-diagram.md](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/architecture-diagram.md)** for the rendered diagrams —
 system topology, runtime message flow through the staged queue, and the config wiring graph (Mermaid,
 renders on GitHub and in the VS Code preview). The prose source of truth is
-[docs/ARCHITECTURE.md](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/ARCHITECTURE.md).
+[docs/ARCHITECTURE.md](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/ARCHITECTURE.md).
 
 ### Key decisions
 - **Reliable by default.** A durable, transactional pipeline gives at-least-once delivery,
@@ -113,7 +120,7 @@ renders on GitHub and in the VS Code preview). The prose source of truth is
 - **PHI is first-class.** Authentication, RBAC, a user-attributed audit log of message
   views/replays, **encryption-at-rest** for message bodies (AES-256-GCM), **global PHI log redaction**,
   and **transport TLS** (HTTPS/WSS for the API plus MLLP-over-TLS) are **built**; MFA and off-box log
-  shipping remain on the roadmap. See [docs/PHI.md](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/PHI.md) for the full data-protection map.
+  shipping remain on the roadmap. See [docs/PHI.md](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/PHI.md) for the full data-protection map.
 
 ## Features
 
@@ -132,9 +139,9 @@ transport TLS — and it runs single-node or in active-passive high availability
 
 Full documentation lives on **[messagefoundry.org](https://messagefoundry.org/)**:
 
-- **[Mental map](https://messagefoundry.org/assets/docs/MessageFoundry-Mental-Model.pdf)** — a one-page
-  picture of how the pieces fit: Connections → Router → Handlers → Connections, with the headless
-  engine and the console/IDE that drive it.
+- **[Mental map](https://messagefoundry.org/assets/docs/MessageFoundry-Mental-Model.pdf)** — an
+  orientation guide to how the pieces fit: Connections → Router → Handlers → Connections, with the
+  headless engine and the console/IDE that drive it.
 - **[Install Guide](https://messagefoundry.org/assets/docs/MessageFoundry-Install-Guide.pdf)** — install,
   configure, secure, and roll out to production.
 - **[User Guide](https://messagefoundry.org/assets/docs/MessageFoundry-User-Guide.pdf)** — author and
@@ -149,7 +156,7 @@ Full documentation lives on **[messagefoundry.org](https://messagefoundry.org/)*
 **The recommended way to deploy MessageFoundry is to install the published package from
 [PyPI](https://pypi.org/project/messagefoundry/)** — a signed, version-pinned wheel is the
 supported production artifact, with no source checkout required. Install it as a **pinned
-dependency**, then scaffold your own config repo ([ADR 0017](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/adr/0017-consumer-deployment-model.md)):
+dependency**, then scaffold your own config repo ([ADR 0017](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/adr/0017-consumer-deployment-model.md)):
 
 ```bash
 pip install "messagefoundry==<version>"   # pin the exact engine version (core runtime, SQLite store)
@@ -181,8 +188,8 @@ 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
-> `gh attestation verify <wheel> --repo wshallwshall/MessageFoundry`, or pull the signed wheel + SBOM
-> from the [GitHub Release assets](https://github.com/wshallwshall/MessageFoundry/releases). For an
+> `gh attestation verify <wheel> --repo MEFORORG/MessageFoundry`, or pull the signed wheel + SBOM
+> from the [GitHub Release assets](https://github.com/MEFORORG/MessageFoundry/releases). For an
 > air-gapped site, mirror the wheel to a private index.
 >
 > *(Engine developers install from a checkout instead — see [Development](#development).)*
@@ -219,14 +226,14 @@ python -m messagefoundry.console --url http://127.0.0.1:8765
 
 ### VS Code extension & test harness
 
-- **VS Code extension** ([`ide/`](https://github.com/wshallwshall/MessageFoundry/tree/main/ide/)) — author and test interfaces in your editor: a New Route
+- **VS Code extension** ([`ide/`](https://github.com/MEFORORG/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. **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
+  + Open VSX publishing is **planned** (see [the backlog](https://github.com/MEFORORG/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).
+  [ide/README.md](https://github.com/MEFORORG/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
@@ -235,14 +242,14 @@ python -m messagefoundry.console --url http://127.0.0.1:8765
 ## License
 
 MessageFoundry is licensed under the **GNU Affero General Public License v3.0 or later**
-(`AGPL-3.0-or-later`) — see [LICENSE](https://github.com/wshallwshall/MessageFoundry/blob/main/LICENSE). Running a modified version as a network service
+(`AGPL-3.0-or-later`) — see [LICENSE](https://github.com/MEFORORG/MessageFoundry/blob/main/LICENSE). Running a modified version as a network service
 triggers the AGPL's §13 source-offer obligation. A separately-licensed commercial edition is planned
 by **MessageFoundry Organization** under the standard open-core model — see
-[COMMERCIAL-LICENSE.md](https://github.com/wshallwshall/MessageFoundry/blob/main/COMMERCIAL-LICENSE.md) (terms pending legal review). See [NOTICE](https://github.com/wshallwshall/MessageFoundry/blob/main/NOTICE)
+[COMMERCIAL-LICENSE.md](https://github.com/MEFORORG/MessageFoundry/blob/main/COMMERCIAL-LICENSE.md) (terms pending legal review). See [NOTICE](https://github.com/MEFORORG/MessageFoundry/blob/main/NOTICE)
 for copyright and attribution.
 
 ## Contributing
 
-Contributions are welcome — see [CONTRIBUTING.md](https://github.com/wshallwshall/MessageFoundry/blob/main/CONTRIBUTING.md), our
-[Code of Conduct](https://github.com/wshallwshall/MessageFoundry/blob/main/CODE_OF_CONDUCT.md), and how the project is governed in [GOVERNANCE.md](https://github.com/wshallwshall/MessageFoundry/blob/main/GOVERNANCE.md).
-A signed [Contributor License Agreement](https://github.com/wshallwshall/MessageFoundry/blob/main/CLA.md) is required before a pull request can be merged.
+Contributions are welcome — see [CONTRIBUTING.md](https://github.com/MEFORORG/MessageFoundry/blob/main/CONTRIBUTING.md), our
+[Code of Conduct](https://github.com/MEFORORG/MessageFoundry/blob/main/CODE_OF_CONDUCT.md), and how the project is governed in [GOVERNANCE.md](https://github.com/MEFORORG/MessageFoundry/blob/main/GOVERNANCE.md).
+A signed [Contributor License Agreement](https://github.com/MEFORORG/MessageFoundry/blob/main/CLA.md) is required before a pull request can be merged.

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/README.md

@@ -1,9 +1,12 @@
 # MessageFoundry
 
-[![CI](https://github.com/wshallwshall/MessageFoundry/actions/workflows/ci.yml/badge.svg)](https://github.com/wshallwshall/MessageFoundry/actions/workflows/ci.yml)
-[![Security](https://github.com/wshallwshall/MessageFoundry/actions/workflows/security.yml/badge.svg)](https://github.com/wshallwshall/MessageFoundry/actions/workflows/security.yml)
-[![License: AGPL v3](https://img.shields.io/badge/License-AGPL_v3-blue.svg)](https://github.com/wshallwshall/MessageFoundry/blob/main/LICENSE)
-[![Python 3.14+](https://img.shields.io/badge/python-3.14%2B-blue.svg)](https://github.com/wshallwshall/MessageFoundry/blob/main/pyproject.toml)
+[![CI](https://github.com/MEFORORG/MessageFoundry/actions/workflows/ci.yml/badge.svg)](https://github.com/MEFORORG/MessageFoundry/actions/workflows/ci.yml)
+[![Security](https://github.com/MEFORORG/MessageFoundry/actions/workflows/security.yml/badge.svg)](https://github.com/MEFORORG/MessageFoundry/actions/workflows/security.yml)
+[![License: AGPL v3](https://img.shields.io/badge/License-AGPL_v3-blue.svg)](https://github.com/MEFORORG/MessageFoundry/blob/main/LICENSE)
+[![Python 3.14+](https://img.shields.io/badge/python-3.14%2B-blue.svg)](https://github.com/MEFORORG/MessageFoundry/blob/main/pyproject.toml)
+
+**Website & documentation: [messagefoundry.org](https://messagefoundry.org/)** ·
+**[Changelog](https://github.com/MEFORORG/MessageFoundry/blob/main/CHANGELOG.md)**
 
 MessageFoundry is an **open-source healthcare integration engine** — a modern, Python-native HL7
 interface engine. It connects clinical and business systems by routing, transforming, and validating
@@ -30,10 +33,10 @@ The PySide6 console talks to it over a localhost HTTP + WebSocket API — the sa
 whether the engine runs in-process, as a local daemon, or (later) on a remote host.
 No hand-rolled IPC; the deployment split is a config choice, not an architectural fork.
 
-See **[docs/architecture-diagram.md](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/architecture-diagram.md)** for the rendered diagrams —
+See **[docs/architecture-diagram.md](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/architecture-diagram.md)** for the rendered diagrams —
 system topology, runtime message flow through the staged queue, and the config wiring graph (Mermaid,
 renders on GitHub and in the VS Code preview). The prose source of truth is
-[docs/ARCHITECTURE.md](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/ARCHITECTURE.md).
+[docs/ARCHITECTURE.md](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/ARCHITECTURE.md).
 
 ### Key decisions
 - **Reliable by default.** A durable, transactional pipeline gives at-least-once delivery,
@@ -47,7 +50,7 @@ renders on GitHub and in the VS Code preview). The prose source of truth is
 - **PHI is first-class.** Authentication, RBAC, a user-attributed audit log of message
   views/replays, **encryption-at-rest** for message bodies (AES-256-GCM), **global PHI log redaction**,
   and **transport TLS** (HTTPS/WSS for the API plus MLLP-over-TLS) are **built**; MFA and off-box log
-  shipping remain on the roadmap. See [docs/PHI.md](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/PHI.md) for the full data-protection map.
+  shipping remain on the roadmap. See [docs/PHI.md](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/PHI.md) for the full data-protection map.
 
 ## Features
 
@@ -66,9 +69,9 @@ transport TLS — and it runs single-node or in active-passive high availability
 
 Full documentation lives on **[messagefoundry.org](https://messagefoundry.org/)**:
 
-- **[Mental map](https://messagefoundry.org/assets/docs/MessageFoundry-Mental-Model.pdf)** — a one-page
-  picture of how the pieces fit: Connections → Router → Handlers → Connections, with the headless
-  engine and the console/IDE that drive it.
+- **[Mental map](https://messagefoundry.org/assets/docs/MessageFoundry-Mental-Model.pdf)** — an
+  orientation guide to how the pieces fit: Connections → Router → Handlers → Connections, with the
+  headless engine and the console/IDE that drive it.
 - **[Install Guide](https://messagefoundry.org/assets/docs/MessageFoundry-Install-Guide.pdf)** — install,
   configure, secure, and roll out to production.
 - **[User Guide](https://messagefoundry.org/assets/docs/MessageFoundry-User-Guide.pdf)** — author and
@@ -83,7 +86,7 @@ Full documentation lives on **[messagefoundry.org](https://messagefoundry.org/)*
 **The recommended way to deploy MessageFoundry is to install the published package from
 [PyPI](https://pypi.org/project/messagefoundry/)** — a signed, version-pinned wheel is the
 supported production artifact, with no source checkout required. Install it as a **pinned
-dependency**, then scaffold your own config repo ([ADR 0017](https://github.com/wshallwshall/MessageFoundry/blob/main/docs/adr/0017-consumer-deployment-model.md)):
+dependency**, then scaffold your own config repo ([ADR 0017](https://github.com/MEFORORG/MessageFoundry/blob/main/docs/adr/0017-consumer-deployment-model.md)):
 
 ```bash
 pip install "messagefoundry==<version>"   # pin the exact engine version (core runtime, SQLite store)
@@ -115,8 +118,8 @@ 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
-> `gh attestation verify <wheel> --repo wshallwshall/MessageFoundry`, or pull the signed wheel + SBOM
-> from the [GitHub Release assets](https://github.com/wshallwshall/MessageFoundry/releases). For an
+> `gh attestation verify <wheel> --repo MEFORORG/MessageFoundry`, or pull the signed wheel + SBOM
+> from the [GitHub Release assets](https://github.com/MEFORORG/MessageFoundry/releases). For an
 > air-gapped site, mirror the wheel to a private index.
 >
 > *(Engine developers install from a checkout instead — see [Development](#development).)*
@@ -153,14 +156,14 @@ python -m messagefoundry.console --url http://127.0.0.1:8765
 
 ### VS Code extension & test harness
 
-- **VS Code extension** ([`ide/`](https://github.com/wshallwshall/MessageFoundry/tree/main/ide/)) — author and test interfaces in your editor: a New Route
+- **VS Code extension** ([`ide/`](https://github.com/MEFORORG/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. **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
+  + Open VSX publishing is **planned** (see [the backlog](https://github.com/MEFORORG/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).
+  [ide/README.md](https://github.com/MEFORORG/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
@@ -169,14 +172,14 @@ python -m messagefoundry.console --url http://127.0.0.1:8765
 ## License
 
 MessageFoundry is licensed under the **GNU Affero General Public License v3.0 or later**
-(`AGPL-3.0-or-later`) — see [LICENSE](https://github.com/wshallwshall/MessageFoundry/blob/main/LICENSE). Running a modified version as a network service
+(`AGPL-3.0-or-later`) — see [LICENSE](https://github.com/MEFORORG/MessageFoundry/blob/main/LICENSE). Running a modified version as a network service
 triggers the AGPL's §13 source-offer obligation. A separately-licensed commercial edition is planned
 by **MessageFoundry Organization** under the standard open-core model — see
-[COMMERCIAL-LICENSE.md](https://github.com/wshallwshall/MessageFoundry/blob/main/COMMERCIAL-LICENSE.md) (terms pending legal review). See [NOTICE](https://github.com/wshallwshall/MessageFoundry/blob/main/NOTICE)
+[COMMERCIAL-LICENSE.md](https://github.com/MEFORORG/MessageFoundry/blob/main/COMMERCIAL-LICENSE.md) (terms pending legal review). See [NOTICE](https://github.com/MEFORORG/MessageFoundry/blob/main/NOTICE)
 for copyright and attribution.
 
 ## Contributing
 
-Contributions are welcome — see [CONTRIBUTING.md](https://github.com/wshallwshall/MessageFoundry/blob/main/CONTRIBUTING.md), our
-[Code of Conduct](https://github.com/wshallwshall/MessageFoundry/blob/main/CODE_OF_CONDUCT.md), and how the project is governed in [GOVERNANCE.md](https://github.com/wshallwshall/MessageFoundry/blob/main/GOVERNANCE.md).
-A signed [Contributor License Agreement](https://github.com/wshallwshall/MessageFoundry/blob/main/CLA.md) is required before a pull request can be merged.
+Contributions are welcome — see [CONTRIBUTING.md](https://github.com/MEFORORG/MessageFoundry/blob/main/CONTRIBUTING.md), our
+[Code of Conduct](https://github.com/MEFORORG/MessageFoundry/blob/main/CODE_OF_CONDUCT.md), and how the project is governed in [GOVERNANCE.md](https://github.com/MEFORORG/MessageFoundry/blob/main/GOVERNANCE.md).
+A signed [Contributor License Agreement](https://github.com/MEFORORG/MessageFoundry/blob/main/CLA.md) is required before a pull request can be merged.

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/docs/BACKLOG.md

@@ -2419,6 +2419,88 @@ investigation (2026-06-27).
 
 ---
 
+## 47. Embedded-document (base64 attachment) pruning — strip OBX-5 / `mfb64:` blobs after a per-connection window (Mirth attachment-handler parity) (P2)
+
+**Type:** feature — selective PHI/storage minimization. Large **base64-encoded embedded documents** (PDF
+reports, CCD/C-CDA, scanned images) ride inline in messages — in HL7 they arrive in **OBX-5** (ED data
+type), and generically anywhere via the ADR 0028 `mfb64:v1:` carriage marker
+([`adr/0028-base64-binary-carriage-codec.md`](adr/0028-base64-binary-carriage-codec.md)). These blobs are
+often tens to hundreds of KB each and are stored verbatim in the raw message at **every** persisted stage
+(`ingress` → `routed` → `outbound`), so a chatty document feed bloats the store far out of proportion to
+its message *count*. The ask: let **each connection** carry a setting to **purge just the embedded
+documents** after a timeframe, keeping the rest of the message (segments, fields, metadata, disposition)
+intact.
+
+**Gap today.** Retention is all-or-nothing on the whole body: the global `RetentionRunner`
+([`pipeline/retention.py`](../messagefoundry/pipeline/retention.py)) calls `purge_message_bodies`
+([`store/store.py`](../messagefoundry/store/store.py)), which **nulls the entire raw body** keep-metadata,
+store-wide, by message age only. There is no way to evict *only the bulky attachment* while preserving the
+surrounding HL7 (the segments an operator still wants to see), and no per-connection window (that broader
+gap is **#34**). Nothing offloads the blob at ingest either — it rides the pipeline inline.
+
+**What Mirth does (researched 2026-06-26).** Mirth solves this with **two** complementary mechanisms, and
+it's worth deciding which we mirror:
+- **Attachment Handler (offload at ingest).** A per-channel handler on the source connector extracts bulky
+  embedded content *before* the message is stored/transformed — e.g. a **Regex** handler pulls the base64
+  PDF out of OBX-5, a **DICOM**/**JavaScript**/**Custom** handler for other shapes. The extracted bytes go
+  to a **separate attachment table** (`d_ma<channelId>`) and the inline blob is replaced in the message by
+  an **attachment token** (`${ATTACH:...}`); it's reattached on the outbound via the same token. A Base64
+  decode option ([MIRTH-2799](https://www.mirthcorp.com/community/issues/si/jira.issueviews:issue-html/MIRTH-2799/MIRTH-2799.html))
+  stores the *decoded* bytes, not the base64 string. This keeps the main message rows small and avoids
+  loading the blob through every transformer step — the recommended lever to bound DB growth.
+- **Data Pruner (prune after a window).** A scheduled task prunes message **content** and **metadata** on
+  *independent* clocks per channel's Message Storage settings — e.g. keep metadata indefinitely but prune
+  content (incl. attachments) after 1 day. Attachments live in their own tables and are pruned with the
+  content. Pruning runs only when the scheduler is enabled, and *which* messages prune is governed by the
+  per-channel storage/`max_message_age` settings.
+  *(Sources: [Zen Healthcare — The Data Pruner](https://consultzen.com/mirth-connect-tutorial-data-pruner/);
+  [NextGen — Message Pruning Settings](https://docs.nextgen.com/en-US/mirth%C2%AE-connect-by-nextgen-healthcare-user-guide-3273569/message-pruning-settings-14245);
+  [CapMinds — high-volume CCD/C-CDA channels](https://www.capminds.com/blog/optimizing-mirth-connect-channels-for-high-volume-ccd-c-cda-document-workflows/).)*
+
+**Design fork (for the ADR).** The user's literal ask is the **prune-after-a-window** half (Mirth's Data
+Pruner, attachment-scoped). The more impactful half is **offload-at-ingest** (Mirth's Attachment Handler),
+which stops the bloat at the source instead of carrying it through three stages first. Decide whether to
+build (a) an in-place **selective strip** of the embedded document after a per-connection window — cheaper,
+matches the request, but the blob still bloats the store until the window elapses and is duplicated across
+stages meanwhile; (b) an **ingest-time offload** to a separate attachment store with a placeholder marker
+(true Mirth parity, bounds growth from the start, but a larger build touching the pipeline + a new store
+table + reattach-on-outbound); or (c) both, with (a) as the near-term increment.
+
+**Scope (when built — increment (a)):**
+- A **per-connection `prune_documents_after` window** (with an embedded-doc size threshold), layered over a
+  global default — the same **global-default + per-connection-override** model used for FIFO,
+  `RetryPolicy`, `BuildupThreshold`, and proposed for **#34** retention. Author it on the inbound
+  `ConnectionSpec` and/or as `connections.toml` keys (ADR 0007) so it stays hand-/GUI-editable.
+- A new store purge path (sibling to `purge_message_bodies`) that **rewrites the stored raw in place**,
+  replacing each embedded document with a small **placeholder/tombstone** (size + content-type + a
+  "pruned <ts>" marker) while leaving the rest of the message byte-stable. Target both carriage forms: the
+  generic `mfb64:v1:` marker and HL7 **OBX-5 ED** embeds. **Never string-slice raw HL7** (CLAUDE.md §8) —
+  edit via the parsed model / codec and re-encode. Must land on **all three** backends (SQLite / Postgres /
+  SQL Server).
+- Preserve every invariant: **never delete the row** (counts / disposition / audit stay intact), the
+  message remains parseable after the strip, and emit **one audit entry per pass** recording the
+  per-connection window + counts + bytes reclaimed (no message content). Pruning a document is irreversible —
+  surface it as a distinct disposition/flag so an operator viewing the message knows the attachment was
+  evicted vs never present.
+
+**Out of scope / leave to siblings:** whole-message retention windows and dead-letter pruning are **#34**
+(this is the *document-only*, finer-grained cut — they should share the per-connection-override plumbing).
+`audit_days` stays keep-forever. The ingest-time offload (fork (b)) is its own ADR if pursued.
+
+**Why P2 / on-trigger.** Real document feeds (radiology results with embedded PDFs, CCDs) are exactly where
+store bloat bites, and PHI data-minimization wants the bulky attachment gone on a *shorter* clock than the
+clinical metadata — a standard Mirth operator expectation. But it's not an open exposure on the shipping
+config and wants an ADR (the design fork above) before code. **Trigger:** a feed carrying large OBX-5 / base64
+embedded documents whose volume bloats the store. Relates to **#34** (per-connection retention — shared
+override plumbing), **ADR 0028** (base64 carriage), and **#21**/**#33** (per-connection observability /
+config-UX).
+
+**Source:** owner request (2026-06-26) — "let each connection purge base64 embedded documents (OBX-5 in
+HL7, or other message types) after a timeframe; they bloat the logs — research what Mirth does." Mirth
+attachment-handler + data-pruner behavior researched the same day (citations above).
+
+---
+
 *Everything else from the 2026-06-10 full-codebase review (1 critical, 13 high, 33 medium, 31 low —
 78 findings) has been remediated; see the review report's §6 action order. The two items it still
 sourced — **#1 (SQL Server concurrency)** and **#2 (console off-thread)** — are now both **DONE**

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/docs/SERVICE.md

@@ -91,6 +91,16 @@ definition drifted — the install script is idempotent (it stops and reconfigur
 If the package was installed **non-editable** (a plain `pip install .`), the venv holds a
 snapshot of the old code — run `.venv\Scripts\python.exe -m pip install -e .` first, then restart.
 
+> **⚠ Upgrading from ≤ 0.2.5 → ≥ 0.2.6: tighten the config-dir ACLs first.** The config-directory
+> permission guard (SEC-003 / ADR 0036) did **not** exist in 0.2.5. From 0.2.6 on, `serve` refuses to
+> start against a `--config` directory **writable by a broad principal** (e.g. `Authenticated Users` /
+> `S-1-5-11`) — *"refusing to load config from writable-by-others path …"*. A config dir that inherits
+> that write (common under `C:\srv\…`) therefore **fails its first start after the upgrade**. Lock it
+> down **before** restarting onto the new build — use the surgical recipe under
+> [Lock down the config directory (CONFIG-2)](#lock-down-the-config-directory-config-2)
+> (`icacls /inheritance:d /T` + `/remove:g *S-1-5-11 /T` + grant SYSTEM/Admins), the lighter-touch
+> alternative to a full `/inheritance:r` reset for a shared tree.
+
 ## Start / stop / status
 
 ```powershell
@@ -190,6 +200,15 @@ trust boundary: anyone who can write a `.py` file there can run code as the serv
   (full) and the service account (read+execute). It is **opt-in** because the config dir often lives
   inside a developer's repo where stripping inheritance is surprising — for production, point
   `-Config` at a dedicated admin-owned directory and pass `-LockConfigDir`.
+- **Fix an existing tree that inherits a broad write grant** without a full ACL reset. A config dir
+  placed under a shared root (e.g. `C:\srv\…`) often inherits `Authenticated Users` (`S-1-5-11`)
+  write, which trips the guard below. The lighter-touch alternative to `/inheritance:r` is to break
+  inheritance, surgically drop just the broad principal, and grant the run-as user read+execute:
+  ```powershell
+  icacls "C:\srv\mefor\config" /inheritance:d /T
+  icacls "C:\srv\mefor\config" /remove:g *S-1-5-11 /T
+  icacls "C:\srv\mefor\config" /grant "<run-as-user>:(OI)(CI)RX" /T
+  ```
 - The loader **actively enforces** this at load time (and on `/config/reload`), not just as a
   documented recommendation (ADR 0036, SEC-003):
   - On **Windows** the loader now parses the directory's and each `*.py`'s NTFS owner + DACL and

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/harness/__main__.py

@@ -69,6 +69,24 @@ def main(argv: list[str] | None = None) -> int:
         "--sink-port", type=int, default=2700, help="load: base correlation-sink port"
     )
     parser.add_argument("--sink-ports", type=int, default=1, help="load: contiguous sink ports")
+    parser.add_argument(
+        "--skip-preflight",
+        action="store_true",
+        help="load: skip the 'engine serves all target ports' check — for driving a `supervise` "
+        "multi-shard cluster from one harness (the MLLP ports are spread across the shard engines, "
+        "so no single --engine serves them all). Point every shard's MEFOR_LOAD_SINK_PORT at this "
+        "run's --sink-port so the one correlation sink aggregates all shards' end-to-end throughput.",
+    )
+    parser.add_argument(
+        "--shard-engine",
+        action="append",
+        metavar="URL",
+        help="load: an EXTRA engine API base URL to poll + aggregate alongside --engine (repeatable). "
+        "Drives a `supervise` multi-shard cluster: pass --engine for the primary shard and one "
+        "--shard-engine per other shard, and the harness sums every shard's /stats so the no-loss "
+        "reconcile + drain see true cluster totals. Pair with --skip-preflight (no one engine serves "
+        "all MLLP ports). With none given the single --engine is polled exactly as before.",
+    )
     parser.add_argument("--report-json", help="load: write the JSON report to this path")
     parser.add_argument("--report-csv", help="load: write the per-phase CSV to this path")
     parser.add_argument("--baseline", help="load: compare against this saved JSON report")
@@ -166,6 +184,8 @@ def _run_load(args: argparse.Namespace) -> int:
                 sink_port=args.sink_port,
                 sink_ports=args.sink_ports,
                 db_backend=args.db_backend,
+                skip_preflight=args.skip_preflight,
+                shard_engines=tuple(args.shard_engine or ()),
             )
         )
     except PreflightError as exc:

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/harness/config/load/_shape.py

@@ -18,6 +18,14 @@ Knobs (all optional, with safe defaults so ``serve`` works with none set):
 * ``MEFOR_LOAD_ADT_PORT``       — ADT hub inbound MLLP port (default 2600).
 * ``MEFOR_LOAD_RESULTS_PORT``   — results hub inbound MLLP port (default 2601).
 * ``MEFOR_LOAD_OTHER_PORT``     — other hub inbound MLLP port (default 2602).
+* ``MEFOR_LOAD_SHARD_ADT``      — ``supervise`` shard id for the ADT hub (default unset → no tag).
+* ``MEFOR_LOAD_SHARD_RESULTS``  — ``supervise`` shard id for the results hub (default unset → no tag).
+* ``MEFOR_LOAD_SHARD_OTHER``    — ``supervise`` shard id for the other hub (default unset → no tag).
+
+Shards (all optional): tagging a hub with ``shard=`` routes it to a named ``messagefoundry supervise``
+subprocess. **Unset (the default) = no tag = a single implicit shard**, so the SAME load graph serves
+both unsharded (default) and sharded (e.g. ``MEFOR_LOAD_SHARD_ADT=a`` / ``_RESULTS=b`` / ``_OTHER=b``
+→ a 2-shard layout) with no other change. The tags never affect routing.
 
 The graph is **synthetic and generic** — it models the *shape* of a high-fan-out estate (one big ADT
 hub plus results/orders hubs), never a real site. See ``docs/LOAD-TESTING.md``.
@@ -64,6 +72,13 @@ def _env_float(name: str, default: float, *, minimum: float = 0.0) -> float:
     return value
 
 
+def _env_shard(name: str) -> str | None:
+    """A shard id from the environment, or ``None`` when unset/blank (= no shard tag)."""
+    raw = os.environ.get(name)
+    raw = raw.strip() if raw else ""
+    return raw or None
+
+
 @dataclass(frozen=True)
 class Shape:
     """Resolved load-graph parameters (read once from the environment at load time)."""
@@ -78,6 +93,9 @@ class Shape:
     adt_port: int
     results_port: int
     other_port: int
+    shard_adt: str | None
+    shard_results: str | None
+    shard_other: str | None
 
     def sink_endpoint(self, index: int) -> tuple[str, int]:
         """Round-robin a destination index across the contiguous sink port range."""
@@ -101,6 +119,9 @@ def load_shape() -> Shape:
         adt_port=_env_int("MEFOR_LOAD_ADT_PORT", 2600, minimum=1),
         results_port=_env_int("MEFOR_LOAD_RESULTS_PORT", 2601, minimum=1),
         other_port=_env_int("MEFOR_LOAD_OTHER_PORT", 2602, minimum=1),
+        shard_adt=_env_shard("MEFOR_LOAD_SHARD_ADT"),
+        shard_results=_env_shard("MEFOR_LOAD_SHARD_RESULTS"),
+        shard_other=_env_shard("MEFOR_LOAD_SHARD_OTHER"),
     )
 
 

{messagefoundry-0.2.6 → messagefoundry-0.2.8}/harness/config/load/graph.py

@@ -69,10 +69,19 @@ _OTH_HANDLERS = _register_lane("OTH", _SHAPE.results_fanout, _SHAPE)
 
 
 # Three inbound MLLP hubs matching the load profiles' target ports. Each fans every received message
-# to its lane's full handler set (the sender sends only the matching types to each port).
-inbound("IB_Load_ADT", MLLP(port=_SHAPE.adt_port), router="adt_router")
-inbound("IB_Load_Results", MLLP(port=_SHAPE.results_port), router="results_router")
-inbound("IB_Load_Other", MLLP(port=_SHAPE.other_port), router="other_router")
+# to its lane's full handler set (the sender sends only the matching types to each port). Each hub may
+# be tagged to a `supervise` shard via MEFOR_LOAD_SHARD_* (default unset → shard=None → no tag → a
+# single implicit shard = byte-identical to the unsharded graph); see _shape.
+inbound("IB_Load_ADT", MLLP(port=_SHAPE.adt_port), router="adt_router", shard=_SHAPE.shard_adt)
+inbound(
+    "IB_Load_Results",
+    MLLP(port=_SHAPE.results_port),
+    router="results_router",
+    shard=_SHAPE.shard_results,
+)
+inbound(
+    "IB_Load_Other", MLLP(port=_SHAPE.other_port), router="other_router", shard=_SHAPE.shard_other
+)
 
 
 @router("adt_router")