factorysemantics-mes 0.1.2__tar.gz → 0.2.0__tar.gz

{factorysemantics_mes-0.1.2 → factorysemantics_mes-0.2.0}/.env.example

@@ -7,6 +7,32 @@ MES_DATABASE_URL=sqlite:///fsmes.db
 # PostgreSQL (scale deployment, matches docker-compose):
 # MES_DATABASE_URL=postgresql+psycopg://mes:mes@localhost:5432/mes_twin
 
+# --- Which plant is this --------------------------------------------------
+# The shape of this deployment: laptop | plant | fleet. `laptop` is the
+# evaluation profile - `fsmes demo` and the labs - and needs nothing else set
+# here. Anything else refuses to start without a plant name.
+MES_PLANT_PROFILE=laptop
+# What this plant is called. It appears on every screen, in /health, on every
+# metric, in every backup and on every namespace event, so a person looking
+# at two plants can tell which one they are looking at. Letters, digits and
+# _ . : @ = - only: it is published as one segment of the namespace topic.
+# MES_PLANT_NAME=northgate
+# The zone this plant works in, as an IANA name. It decides where a shift
+# starts, when a gauge falls due, and what time every screen shows. Left out,
+# the MES uses this machine's own zone and says "defaulted" wherever it
+# reports it. On Windows the zone database comes from `pip install tzdata`.
+# MES_PLANT_TIMEZONE=America/Chicago
+
+# --- Shadow mode ----------------------------------------------------------
+# The MES watches a real plant and can change nothing in it: no PLC
+# write-back, no live ERP, no MQTT publish, nothing about this plant off the
+# box. This is how you run it beside the MES already in charge on a line.
+# Read once at start-up; leaving it is a restart, recorded in the audit
+# trail. With it on, MES_ERP_MODE may only be off or file and MES_UNS_MODE
+# only off or log - anything else refuses to start and says which variable.
+# See docs/operate/shadow-mode.md.
+MES_SHADOW=false
+
 # --- Logging --------------------------------------------------------------
 MES_LOG_LEVEL=INFO
 MES_LOG_DIR=logs
@@ -59,7 +85,9 @@ MES_ERPNEXT_PASSWORD=admin   # the Frappe dev-bench default; a real site uses th
 # Preferred for a long-running worker (ERPNext: User -> API Access -> generate):
 # MES_ERPNEXT_API_KEY=
 # MES_ERPNEXT_API_SECRET=
-MES_ERPNEXT_COMPANY=ACME Beverages
+# Which company's work orders to import. Empty (the default) imports every
+# company's; a bench serving more than one company must set this.
+# MES_ERPNEXT_COMPANY=Your Company
 # Post finished quantities as real Manufacture stock entries. Off records what
 # the MES counted without moving ERPNext's stock.
 MES_ERPNEXT_POST_STOCK_ENTRY=true

factorysemantics_mes-0.2.0/.github/scripts/demo_from_wheel.sh

@@ -0,0 +1,64 @@
+#!/usr/bin/env bash
+# Prove a built wheel runs the demo, with nothing but the wheel to run it from.
+#
+# 0.1.0 installed cleanly from PyPI and did not work: the wheel carried no
+# config/tag_map.json, so the simulator had no line, nothing was ever booked,
+# and `fsmes demo` exited 0 regardless. The Release Checklist's clean-machine
+# install was the line that would have caught it, and it was skipped for
+# speed. This is that line, automated, so speed cannot skip it.
+#
+# Usage: demo_from_wheel.sh <wheel> [duration-seconds]
+set -euo pipefail
+
+wheel_arg="${1:?usage: demo_from_wheel.sh <wheel> [duration-seconds]}"
+wheel="$(cd "$(dirname "$wheel_arg")" && pwd)/$(basename "$wheel_arg")"
+# The demo stops watching after this many seconds; it exits as soon as the
+# order completes, so a generous number costs nothing when the wheel is good.
+duration="${2:-300}"
+
+# An empty directory containing none of the repository's files. That is the
+# whole point: no config/, no .env, no fsmes.db, no src/ to import instead of
+# the installed package.
+work="$(mktemp -d)"
+trap 'rm -rf "$work"' EXIT
+cd "$work"
+
+python -m venv .venv
+.venv/bin/python -m pip install --quiet --upgrade pip
+.venv/bin/python -m pip install --quiet "$wheel"
+# What the wheel says it is, asked two ways: the distribution metadata pip
+# installed, and the answer a user gets from the command line. These were a
+# version apart in 0.1.2 — the metadata said 0.1.2, `fsmes --version` said
+# 0.1.0 — because the number was written down twice. It is written down once
+# now (src/fsmes/__init__.py, which hatchling stamps the metadata from), and
+# this is the line that keeps it that way: a wheel whose two answers disagree
+# never reaches PyPI.
+echo "wheel: $(basename "$wheel")"
+metadata_version="$(.venv/bin/python -c "from importlib.metadata import version; print(version('factorysemantics-mes'))")"
+reported_version="$(.venv/bin/fsmes --version)"
+echo "installed: ${metadata_version}"
+echo "fsmes --version: ${reported_version}"
+if [ "$reported_version" != "fsmes ${metadata_version}" ]; then
+    echo "::error::the wheel's metadata says ${metadata_version} but 'fsmes --version' says '${reported_version}'"
+    exit 1
+fi
+
+set +e
+timeout 900 .venv/bin/fsmes demo --duration "$duration" 2>&1 | tee demo.log
+exit_code="${PIPESTATUS[0]}"
+set -e
+
+# Two separate questions, and both have to be asked. The exit code only became
+# meaningful when the demo learned to fail; an older wheel exits 0 while
+# booking nothing, and only the output tells you which one you have.
+if [ "$exit_code" -ne 0 ]; then
+    echo "::error::fsmes demo exited ${exit_code} from the built wheel"
+    exit 1
+fi
+
+if ! grep -q "Demo result: full loop closed" demo.log; then
+    echo "::error::the wheel installed but the demo never closed its loop"
+    exit 1
+fi
+
+echo "The wheel ran the demo to a closed loop."

factorysemantics_mes-0.2.0/.github/scripts/upgrade_from_previous_release.sh

@@ -0,0 +1,95 @@
+#!/usr/bin/env bash
+# Prove the upgrade a plant will actually perform: a database made by the
+# release that is on PyPI now, moved to the current schema by the built wheel.
+#
+# 0.1.2 shipped no migration scripts inside the wheel, so `fsmes init-db`
+# outside a source checkout created any missing tables with create_all, ran no
+# ALTER at all, and printed "Database schema is up to date" either way. A plant
+# that installed from PyPI and upgraded would have run new code against an old
+# schema and been told everything was fine. That is an honesty bug caused by
+# packaging, and packaging bugs are invisible to every test that runs in a
+# checkout — so this runs on the bytes that ship.
+#
+# Usage: upgrade_from_previous_release.sh <wheel>
+set -euo pipefail
+
+wheel_arg="${1:?usage: upgrade_from_previous_release.sh <wheel>}"
+wheel="$(cd "$(dirname "$wheel_arg")" && pwd)/$(basename "$wheel_arg")"
+
+# An empty directory: no config/, no alembic.ini, no src/ to import instead of
+# the installed package. The same nothing a plant PC has.
+work="$(mktemp -d)"
+trap 'rm -rf "$work"' EXIT
+cd "$work"
+
+# Counts every row in the database, so the upgrade can be shown not to have
+# lost any. A plant's history is the thing a migration must never trade away.
+cat > rows.py <<'PY'
+import sqlite3
+
+conn = sqlite3.connect("fsmes.db")
+tables = [row[0] for row in conn.execute(
+    "SELECT name FROM sqlite_master WHERE type='table' "
+    "AND name NOT LIKE 'sqlite_%' AND name != 'alembic_version'")]
+print(sum(conn.execute(f'SELECT count(*) FROM "{table}"').fetchone()[0] for table in tables))
+PY
+
+# The release a plant is upgrading *from*: whatever PyPI serves today. Named
+# rather than pinned, so this keeps testing the real starting point as
+# releases go by instead of testing 0.1.2 forever.
+python -m venv .venv-previous
+.venv-previous/bin/python -m pip install --quiet --upgrade pip
+.venv-previous/bin/python -m pip install --quiet factorysemantics-mes
+previous="$(.venv-previous/bin/python -c "from importlib.metadata import version; print(version('factorysemantics-mes'))")"
+echo "previous release, from PyPI: ${previous}"
+
+# A database, made the way that release makes one, with rows in it.
+.venv-previous/bin/fsmes init-db
+.venv-previous/bin/fsmes seed
+before_rows="$(python rows.py)"
+echo "rows in the ${previous} database: ${before_rows}"
+if [ "$before_rows" -lt 1 ]; then
+    echo "::error::the ${previous} wheel produced an empty database, so this would prove nothing"
+    exit 1
+fi
+
+# The wheel under test, in its own environment, pointed at that same database.
+python -m venv .venv-built
+.venv-built/bin/python -m pip install --quiet --upgrade pip
+.venv-built/bin/python -m pip install --quiet "$wheel"
+built="$(.venv-built/bin/python -c "from importlib.metadata import version; print(version('factorysemantics-mes'))")"
+echo "built wheel: ${built}"
+
+.venv-built/bin/fsmes init-db 2>&1 | tee upgrade.log
+
+# `db-status` exits non-zero unless the stamp equals the head the wheel ships.
+# That is the promise being made to the plant, asked of the database itself.
+if ! .venv-built/bin/fsmes db-status; then
+    echo "::error::a ${previous} database upgraded with the built wheel is not at head"
+    exit 1
+fi
+
+after_rows="$(python rows.py)"
+echo "rows after the upgrade: ${after_rows}"
+if [ "$after_rows" -lt "$before_rows" ]; then
+    echo "::error::the upgrade lost rows: ${before_rows} before, ${after_rows} after"
+    exit 1
+fi
+
+# And the software still works on the database it just moved: the demo, run
+# against the upgraded file rather than a fresh one. That is the difference
+# between "the migrations ran" and "the plant can carry on".
+set +e
+timeout 900 .venv-built/bin/fsmes demo --duration 300 2>&1 | tee demo.log
+exit_code="${PIPESTATUS[0]}"
+set -e
+if [ "$exit_code" -ne 0 ]; then
+    echo "::error::fsmes demo exited ${exit_code} on a database upgraded from ${previous}"
+    exit 1
+fi
+if ! grep -q "Demo result: full loop closed" demo.log; then
+    echo "::error::the upgraded database ran the demo, but the loop never closed"
+    exit 1
+fi
+
+echo "A ${previous} database upgraded to head with the built wheel, kept its ${after_rows} rows, and ran the demo."

factorysemantics_mes-0.2.0/.github/workflows/ci.yml

@@ -0,0 +1,179 @@
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+  workflow_call:
+
+permissions:
+  contents: read
+
+jobs:
+  test:
+    runs-on: ${{ matrix.os }}
+    strategy:
+      fail-fast: false
+      matrix:
+        # Windows is a first-class target, not an afterthought: this MES is
+        # expected to run on plant PCs, and the single-writer lock exists in
+        # its O_EXCL form precisely because there is no fcntl there.
+        os: [ubuntu-latest, windows-latest]
+        python-version: ["3.12", "3.13"]
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install
+        run: python -m pip install --upgrade pip && python -m pip install -e ".[dev,mcp,agent]"
+
+      - name: Lint
+        run: python -m ruff check .
+
+      - name: Test
+        run: python -m pytest
+
+  postgres:
+    # The suite against a real PostgreSQL, because a plant runs one.
+    #
+    # Everything else here runs on in-memory SQLite. SQLite is forgiving in
+    # ways PostgreSQL is not — LIKE ignores case, GROUP BY tolerates a bare
+    # column, a failed statement does not poison the transaction — so a bug
+    # that only shows on PostgreSQL is invisible to the rest of this file.
+    # This cell is where it shows: on a runner, not on a plant PC.
+    #
+    # One cell, Ubuntu, one Python. What this catches is a dialect
+    # difference, not a platform or interpreter difference, so multiplying
+    # the matrix would buy nothing and cost four times the minutes.
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+
+    services:
+      postgres:
+        # Pinned by digest, not by tag: `postgres:16` is a moving target and
+        # a green run has to mean the same bytes passed. This is 16.15.
+        # Moving the pin is a pull request, which is when it gets re-proven.
+        image: postgres@sha256:f1c3376c26f2609ab9f29f71f824103fe2fcd8ee0346485cb6122a4f93df6f94
+        env:
+          POSTGRES_USER: fsmes
+          POSTGRES_PASSWORD: fsmes
+          POSTGRES_DB: fsmes
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd "pg_isready -U fsmes -d fsmes"
+          --health-interval 5s
+          --health-timeout 5s
+          --health-retries 20
+
+    env:
+      # The suite's database. Not MES_DATABASE_URL — see tests/conftest.py for
+      # why the two are kept apart.
+      MES_TEST_DATABASE_URL: postgresql+psycopg://fsmes:fsmes@127.0.0.1:5432/fsmes
+      # Alembic reads the deployment setting, so the migration step below
+      # points that at the same server.
+      MES_DATABASE_URL: postgresql+psycopg://fsmes:fsmes@127.0.0.1:5432/fsmes
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      # The same extras as `test`, plus the PostgreSQL driver.
+      - name: Install
+        run: python -m pip install --upgrade pip && python -m pip install -e ".[dev,mcp,agent,postgres]"
+
+      # First, while the database is still empty: the migrations. A chain
+      # that has only ever run on SQLite is the likeliest thing here to be
+      # quietly wrong, and `alembic upgrade head` from nothing is the only
+      # way a plant ever gets its schema. One head, checked here as well as
+      # in the suite, because a second head fails this step in a way that is
+      # hard to read otherwise.
+      - name: alembic upgrade head, from empty, on PostgreSQL
+        run: |
+          set -euo pipefail
+          heads=$(python -m alembic heads | grep -c . || true)
+          if [ "$heads" != "1" ]; then
+            echo "expected exactly one migration head, found $heads:"
+            python -m alembic heads --verbose
+            exit 1
+          fi
+          started=$(date +%s)
+          python -m alembic upgrade head
+          echo "PG_ALEMBIC_SECONDS=$(( $(date +%s) - started ))" >> "$GITHUB_ENV"
+          python -m alembic current
+          # And the path a plant actually uses: the migrations resolved from
+          # the package rather than from this directory. `db-status` exits
+          # non-zero unless the database is at the head the package ships, so
+          # the two ways of asking have to agree, on PostgreSQL as well.
+          fsmes db-status
+
+      # The suite drops the migrated schema and builds its own from the
+      # model, which is the same thing every other cell does. Running it
+      # second means the step above genuinely started from empty.
+      - name: Test
+        run: |
+          set -euo pipefail
+          started=$(date +%s)
+          python -m pytest
+          echo "PG_TEST_SECONDS=$(( $(date +%s) - started ))" >> "$GITHUB_ENV"
+
+      - name: What this run cost
+        if: always()
+        run: |
+          {
+            echo "| Step | Seconds |"
+            echo "|---|---|"
+            echo "| alembic upgrade head | ${PG_ALEMBIC_SECONDS:-—} |"
+            echo "| Suite on PostgreSQL 16.15 | ${PG_TEST_SECONDS:-—} |"
+          } >> "$GITHUB_STEP_SUMMARY"
+
+  wheel-demo:
+    # The check that would have caught 0.1.0. `test` above proves the source
+    # works; this proves the *artifact* works — installed into a fresh venv in
+    # an empty directory, which is all a stranger with pipx ever has. One cell
+    # on Ubuntu and one Python is enough: what this catches is missing package
+    # data, not a platform difference.
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - run: python -m pip install --upgrade pip build
+      - run: python -m build --wheel
+      - name: The wheel runs the demo from an empty directory
+        run: .github/scripts/demo_from_wheel.sh "$(ls dist/*.whl)"
+
+      # And the other thing a plant does with a wheel: upgrade the database it
+      # already has. Until 2026-09-10 the wheel carried no migration scripts,
+      # so `fsmes init-db` outside a checkout ran no ALTER and said the schema
+      # was up to date - which would have put a plant on new code and an old
+      # schema, quietly. This installs the release that is on PyPI now, makes
+      # a database with it, upgrades that database with the wheel under test,
+      # and asks the database whether it is at head.
+      - name: The wheel upgrades a database made by the previous release
+        run: .github/scripts/upgrade_from_previous_release.sh "$(ls dist/*.whl)"
+
+  audit:
+    # Known-vulnerable pins. Advisory until the first public release has
+    # shaken it out; then it becomes required.
+    runs-on: ubuntu-latest
+    continue-on-error: true
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.13"
+      # Editable install and --skip-editable, without --strict: the package
+      # under test is not on PyPI at the version being built (or at all,
+      # before the first release), and pip-audit must not count that as a
+      # finding. Vulnerabilities in the dependencies still fail the job.
+      - run: python -m pip install --upgrade pip pip-audit && python -m pip install -e ".[mcp,agent,postgres]"
+      - run: python -m pip_audit --skip-editable

factorysemantics_mes-0.2.0/.github/workflows/erpnext-live.yml

@@ -0,0 +1,165 @@
+# The ERPNext round trip, against a real ERPNext.
+#
+# Its own workflow, not a fifth cell in CI's matrix, for two reasons. It is
+# slow — most of the wall clock is ERPNext installing itself into a fresh
+# site — and red here means something different: not "this change is wrong"
+# but "the MES and ERPNext no longer agree". Those deserve separate names in
+# the checks list.
+#
+# WHEN IT RUNS, AND WHY NOT ALWAYS. On pull requests that touch the ERPNext
+# connector, its tests, its lab fixture or this file; on the same paths when
+# they land on main; and on demand. Not on every pull request, because a job
+# that adds this much to an unrelated typo fix is a job people learn to
+# ignore. Not on a schedule either: every image is pinned to a digest, so a
+# nightly run would test the identical bytes it tested last night and prove
+# nothing. Changing the pin is what makes this worth running again, and that
+# is a pull request touching labs/erpnext/.
+
+name: ERPNext (live)
+
+# The two path lists are the same list written twice: GitHub Actions does not
+# support YAML anchors. Keep them together.
+on:
+  pull_request:
+    paths:
+      - "src/fsmes/integrations/erp/**"
+      - "tests/test_erpnext*.py"
+      - "labs/erpnext/**"
+      - "docs/operate/erpnext.md"
+      - ".github/workflows/erpnext-live.yml"
+  push:
+    branches: [main]
+    paths:
+      - "src/fsmes/integrations/erp/**"
+      - "tests/test_erpnext*.py"
+      - "labs/erpnext/**"
+      - "docs/operate/erpnext.md"
+      - ".github/workflows/erpnext-live.yml"
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: erpnext-live-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  roundtrip:
+    runs-on: ubuntu-latest
+    # Generous, because a red job must be a real disagreement and not a
+    # runner having a slow morning. If it ever gets near this, the compose
+    # is the thing to fix, not the number.
+    timeout-minutes: 45
+
+    env:
+      COMPOSE: labs/erpnext/docker-compose.yml
+      # The whole connection, set the way docs/operate/erpnext.md tells an
+      # operator to set it. MES_ERP_MODE is part of that: the `fsmes erp`
+      # commands are the port's own `requirements`, `setup` and `check`, so
+      # the mode is what decides which connector they act on. Leave it unset
+      # and this job would prepare the file exchange instead.
+      MES_ERP_MODE: erpnext
+      MES_ERPNEXT_BASE_URL: http://127.0.0.1:8080
+      MES_ERPNEXT_SITE: mes.localhost
+      MES_ERPNEXT_USER: Administrator
+      MES_ERPNEXT_PASSWORD: admin
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      # The same extras as ci.yml. Fewer would be enough to run the ERPNext
+      # tests, but pytest collects the whole tree before it selects, and a
+      # module that cannot import is a collection error rather than a
+      # deselected test.
+      - name: Install
+        run: python -m pip install --upgrade pip && python -m pip install -e ".[dev,mcp,agent]"
+
+      # Timed on purpose: the cost of this job is an argument people will
+      # want to have, and it should be settled with the numbers in the log.
+      - name: Start ERPNext and install the site
+        run: |
+          set -euo pipefail
+          started=$(date +%s)
+          docker compose -f "$COMPOSE" up -d
+          echo "ERPNEXT_UP_SECONDS=$(( $(date +%s) - started ))" >> "$GITHUB_ENV"
+          docker compose -f "$COMPOSE" ps
+
+      - name: Wait for the site to answer on the Host header the MES sends
+        run: |
+          set -euo pipefail
+          started=$(date +%s)
+          for attempt in $(seq 1 60); do
+            code=$(curl -s -o /dev/null -w '%{http_code}' \
+              -H "Host: $MES_ERPNEXT_SITE" \
+              "$MES_ERPNEXT_BASE_URL/api/method/frappe.ping" || true)
+            if [ "$code" = "200" ]; then
+              echo "site answered on attempt $attempt of 60"
+              echo "ERPNEXT_READY_SECONDS=$(( $(date +%s) - started ))" >> "$GITHUB_ENV"
+              exit 0
+            fi
+            sleep 5
+          done
+          echo "the site never answered 200 (last status ${code:-none}) after 60 attempts"
+          exit 1
+
+      # The three commands the docs tell an operator to run, run against a
+      # real ERPNext. They are the ERP port's own methods, so this also
+      # proves the port answers for a connector that has real requirements.
+      # `check` exits non-zero when the connector would not work, so a wrong
+      # field type or a missing permission is a red job here rather than a
+      # lost number on someone's plant.
+      - name: fsmes erp requirements, setup, then check
+        run: |
+          set -euo pipefail
+          fsmes erp requirements
+          fsmes erp setup
+          fsmes erp check
+
+      # The same script a person would run against their own bench. It seeds
+      # the plant the round trip needs — company, items, routing, BOM, stock.
+      # If it breaks, the documented way in is broken, and that is worth a red
+      # job on its own.
+      - name: Seed the plant
+        run: |
+          set -euo pipefail
+          started=$(date +%s)
+          python labs/erpnext/seed_erpnext.py \
+            --url "$MES_ERPNEXT_BASE_URL" --site "$MES_ERPNEXT_SITE"
+          echo "ERPNEXT_SEED_SECONDS=$(( $(date +%s) - started ))" >> "$GITHUB_ENV"
+
+      - name: The round trip
+        run: |
+          set -euo pipefail
+          started=$(date +%s)
+          # -s so the missing-field probe's measurement is in the log of a
+          # passing run. It is the point of that test; captured output that
+          # only appears on failure would hide the evidence.
+          python -m pytest -m erpnext_live -v -s
+          echo "ERPNEXT_TEST_SECONDS=$(( $(date +%s) - started ))" >> "$GITHUB_ENV"
+
+      # Frappe puts the reason for a 417 in the worker log, not in the
+      # response. Without this a failure here is unreadable.
+      - name: ERPNext's own logs
+        if: failure()
+        run: docker compose -f "$COMPOSE" logs --tail=400
+
+      - name: What this run cost
+        if: always()
+        run: |
+          {
+            echo "| Step | Seconds |"
+            echo "|---|---|"
+            echo "| ERPNext up, site installed | ${ERPNEXT_UP_SECONDS:-—} |"
+            echo "| Site answering | ${ERPNEXT_READY_SECONDS:-—} |"
+            echo "| Seed | ${ERPNEXT_SEED_SECONDS:-—} |"
+            echo "| Round trip | ${ERPNEXT_TEST_SECONDS:-—} |"
+          } >> "$GITHUB_STEP_SUMMARY"
+
+      - name: Stop ERPNext
+        if: always()
+        run: docker compose -f "$COMPOSE" down -v

{factorysemantics_mes-0.1.2 → factorysemantics_mes-0.2.0}/.github/workflows/release.yml

@@ -25,6 +25,17 @@ jobs:
         run: |
           v="${GITHUB_REF_NAME#v}"
           ls dist/ | grep -q "factorysemantics_mes-${v}-" || { echo "::error::tag $GITHUB_REF_NAME but wheel is $(ls dist/)"; exit 1; }
+      # The wheel's filename comes from src/fsmes/__init__.py now, so the step
+      # above already ties the tag to the number the CLI reports. CITATION.cff
+      # is the one version left that a human types: the citation file format
+      # has no way to read it from the package. It was a release behind when
+      # this check was written, and 0.1.2 is what a wrong number costs. A tag
+      # whose citation disagrees stops here, before anything is published.
+      - name: The tag and the citation file agree
+        run: |
+          v="${GITHUB_REF_NAME#v}"
+          cited="$(sed -n 's/^version: *//p' CITATION.cff)"
+          [ "$cited" = "$v" ] || { echo "::error::tag $GITHUB_REF_NAME but CITATION.cff says ${cited:-nothing}"; exit 1; }
       - name: The wheel carries the demo's config files
         run: |
           python - <<'PY'
@@ -39,9 +50,28 @@ jobs:
           name: dist
           path: dist/
 
-  pypi:
+  wheel-demo:
+    # The `build` job checks the wheel's filename and that the config files
+    # are inside it. Both were true of a wheel that still did not run. This
+    # runs the demo from the exact artifact about to be published — not a
+    # rebuild of it — so a tag cannot publish a wheel that does not work.
     needs: build
     runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+      - uses: actions/download-artifact@v4
+        with:
+          name: dist
+          path: dist/
+      - name: The wheel that is about to be published runs the demo
+        run: .github/scripts/demo_from_wheel.sh "$(ls dist/*.whl)"
+
+  pypi:
+    needs: [build, wheel-demo]
+    runs-on: ubuntu-latest
     environment: pypi
     permissions:
       id-token: write

{factorysemantics_mes-0.1.2 → factorysemantics_mes-0.2.0}/.gitignore

@@ -65,3 +65,6 @@ labs/cutlery/.data/
 docs/reference/
 docs/llms.txt
 site/
+
+# A backup folder written by `fsmes backup`.
+backups/