aslmp 0.1.0__tar.gz

aslmp-0.1.0/.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,192 @@
+name: Bug report
+description: Something in aslmp behaves differently from what it says it does.
+title: "[bug] "
+labels: ["bug"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        **Before anything else.** If your CPU is attached to something that can move,
+        do not reproduce a bug on it. This library writes to PLCs.
+
+        Two reports that belong somewhere else:
+
+        - *"My CPU answers differently from your table."* That is not a bug, it is the
+          most valuable report this project receives — use the **CPU behaviour
+          disagreement** template instead.
+        - A security vulnerability in `aslmp` itself: see `SECURITY.md`, not here.
+
+        Everything below the first two boxes is asking for the conditions of your
+        observation. That is not bureaucracy: this project has twice had to withdraw a
+        published claim because a measurement was recorded without them, and a report
+        about a PLC with no firmware version behind it cannot be acted on.
+
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened, and what you expected instead
+      description: >
+        If an exception was raised, paste the whole diagnostic block — the target,
+        request, sent, received, routes, timing, observed, action and manual lines are
+        each load-bearing. Redact the address or the device values first if they matter
+        to you; say where you redacted.
+      placeholder: |
+        aslmp.SlmpUnsupportedCommandError: end code 0xC059 — "..."
+          target    ...
+          request   ...
+    validations:
+      required: true
+
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: The smallest code that shows it
+      description: >
+        Against the simulator (`aslmp serve`, or `aslmp.testing`) if you can reproduce
+        it there — a simulator repro is one we can fix without your PLC. Say so if it
+        only reproduces against real silicon.
+      render: python
+    validations:
+      required: true
+
+  - type: input
+    id: aslmp-version
+    attributes:
+      label: aslmp version
+      description: "`aslmp --version`, or the commit SHA if you are on a checkout."
+      placeholder: 0.1.0.dev0
+    validations:
+      required: true
+
+  - type: input
+    id: python-and-os
+    attributes:
+      label: Python version and OS
+      description: >
+        `python -VV` and the OS. Both matter here more than usual: clock resolution and
+        socket behaviour differ across them, and one shipped bug in this library existed
+        only on Windows below CPython 3.13.
+      placeholder: "3.11.15, Windows 11"
+    validations:
+      required: true
+
+  - type: input
+    id: cpu-model
+    attributes:
+      label: CPU model
+      description: The exact model as printed on the unit, not the family.
+      placeholder: FX5U-32MT/DS
+    validations:
+      required: true
+
+  - type: input
+    id: firmware
+    attributes:
+      label: CPU firmware version
+      description: >
+        GX Works3 → Diagnostics → Module Diagnostics, the firmware version field. A
+        measurement names one piece of silicon on one firmware; a report without this is
+        not actionable, and "unknown" is a worse answer than a delayed one.
+      placeholder: "1.065"
+    validations:
+      required: true
+
+  - type: dropdown
+    id: profile
+    attributes:
+      label: Profile key
+      description: The string passed to `Plc(profile=...)`. `aslmp identify HOST` prints it.
+      options:
+        - "melsec:iq-f/fx5u"
+        - "melsec:iq-f/fx5uc"
+        - "melsec:iq-f/fx5uj"
+        - "melsec:iq-f/fx5s"
+        - "melsec:iq-r"
+        - "melsec:iq-r/r00"
+        - "melsec:q"
+        - "melsec:l"
+        - "no PLC involved (simulator, unit test, CLI)"
+    validations:
+      required: true
+
+  - type: dropdown
+    id: transport
+    attributes:
+      label: Transport
+      options:
+        - TCP
+        - UDP
+        - not applicable
+    validations:
+      required: true
+
+  - type: dropdown
+    id: frame
+    attributes:
+      label: Frame type
+      options:
+        - 3E
+        - 4E
+        - not applicable
+    validations:
+      required: true
+
+  - type: dropdown
+    id: data-code
+    attributes:
+      label: Communication Data Code
+      description: >
+        On iQ-F this is an **Own Node Setting for the whole Ethernet port**, not a
+        per-entry one. If you are not sure, that is itself worth saying — a coding
+        mismatch produces no response at all rather than an error.
+      options:
+        - Binary
+        - ASCII
+        - not sure
+        - not applicable
+    validations:
+      required: true
+
+  - type: textarea
+    id: connection-entry
+    attributes:
+      label: The connection entry, as GX Works3 has it
+      description: >
+        Port number, and anything unusual: a UDP entry's destination IP, how many entries
+        the CPU has configured, whether anything else was connected at the time. One TCP
+        connection is served per entry, so "something else was on it" explains a whole
+        class of report.
+      placeholder: |
+        TCP, PLC-side port 5002, one of six entries. Nothing else connected.
+    validations:
+      required: true
+
+  - type: input
+    id: host-and-link
+    attributes:
+      label: Host and link
+      description: >
+        Required if your report quotes a latency figure, and useful otherwise. Where the
+        client ran, what is between it and the CPU, and the median RTT if you know it.
+        This project published a transport conclusion that turned out to be a property of
+        its Wi-Fi link; every timing table in this repository now names these.
+      placeholder: "laptop at 192.168.10.41, Wi-Fi, ~7 ms median RTT"
+    validations:
+      required: false
+
+  - type: checkboxes
+    id: confirmations
+    attributes:
+      label: Before you post
+      options:
+        - label: >
+            This is not a security vulnerability report. Those follow `SECURITY.md` —
+            private reporting first, never a public issue.
+          required: true
+        - label: >
+            If I quoted a latency number, I named the host and the link it came from.
+          required: false
+        - label: >
+            I have read `docs/unverified.md` and this is not a path that already ships
+            labelled unverified.
+          required: false

aslmp-0.1.0/.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,32 @@
+# Blank issues are off because both templates exist to collect the conditions of an
+# observation, and a report without them cannot be acted on. Anything that is not a bug
+# and not a CPU disagreement is a question, and questions are better in Discussions,
+# where the answer stays findable.
+blank_issues_enabled: false
+
+contact_links:
+  - name: Question, or "how do I ...?"
+    url: https://github.com/AcaysiaChem/aslmp/discussions
+    about: >
+      Setup, GX Works3 parameters, which profile to pass, why a read came back silent.
+      Ask here — a question is not a defect, and the README's PLC-side section grew out
+      of exactly these.
+
+  - name: Security vulnerability in aslmp
+    url: https://github.com/AcaysiaChem/aslmp/security/policy
+    about: >
+      Do not open a public issue. The reporting address and what we can and cannot fix
+      are in SECURITY.md.
+
+  - name: "SLMP has no authentication and no encryption"
+    url: https://github.com/AcaysiaChem/aslmp/blob/main/SECURITY.md
+    about: >
+      That is a property of the protocol, not a defect in this library, and it is not
+      something we can fix. Read SECURITY.md before reporting it.
+
+  - name: Is this path verified?
+    url: https://github.com/AcaysiaChem/aslmp/blob/main/docs/unverified.md
+    about: >
+      Seven of the eight shipped profiles have never been connected to, and the ASCII
+      path has never been on a wire. If what surprised you is on that page, an issue
+      saying so is still welcome — but the page may already answer it.

aslmp-0.1.0/.github/ISSUE_TEMPLATE/cpu_behaviour.yml

@@ -0,0 +1,159 @@
+name: CPU behaviour disagreement
+description: Your CPU answers differently from a shipped table, or you can close an unverified row.
+title: "[cpu] "
+labels: ["hardware", "provenance"]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        **This is the report this project most wants.** One CPU is the whole of our
+        evidence: a MELSEC iQ-F FX5U-32MT/DS on firmware 1.065. Seven of the eight
+        shipped profiles have never been connected to, the ASCII path has never been on a
+        wire, and `docs/unverified.md` lists every one of them with the experiment that
+        would settle it. An iQ-R, a Q, an L, an FX5UC/FX5UJ/FX5S or an ASCII-coded port
+        turns a row of that page from "the manual says" into "we measured".
+
+        The data files are built to receive this: every row of every table in
+        `src/aslmp/data/` carries a provenance tail — cpu, firmware, measured, host,
+        medium, samples — and a row cannot be marked measured without them. The fields
+        below **are** those columns. Filling them in is most of the work of the change.
+
+        Safety first, as ever: do not probe a CPU that is attached to anything that can
+        move, and note that `aslmp verify-ranges` reads devices the profile would
+        normally refuse (it writes nothing and changes no CPU state).
+
+  - type: textarea
+    id: disagreement
+    attributes:
+      label: What we say, and what your CPU said
+      description: >
+        Name the table or the claim — a device range, a point limit, an end code, a model
+        code, a capability, a line in `docs/unverified.md` or `docs/hardware.md` — and put
+        the CPU's actual answer beside it. End codes and raw bytes are better than prose.
+      placeholder: |
+        ranges_iqr.tsv says melsec:iq-r R has 0 points. On this R04CPU, R32767 reads
+        0x0000 and R32768 returns 0xC056, so the real boundary is 32768 points.
+    validations:
+      required: true
+
+  - type: input
+    id: cpu
+    attributes:
+      label: CPU model
+      description: The exact model, as printed on the unit. `Measurement.cpu`.
+      placeholder: R04CPU
+    validations:
+      required: true
+
+  - type: input
+    id: firmware
+    attributes:
+      label: Firmware version
+      description: >
+        `Measurement.firmware`. GX Works3 → Diagnostics → Module Diagnostics. A firmware
+        update can invalidate any row in this repository, which is why no row exists
+        without this.
+      placeholder: "1.065"
+    validations:
+      required: true
+
+  - type: input
+    id: date
+    attributes:
+      label: Date measured
+      description: "`Measurement.date`. ISO `YYYY-MM-DD`; the type refuses anything else."
+      placeholder: "2026-09-07"
+    validations:
+      required: true
+
+  - type: input
+    id: host
+    attributes:
+      label: Host
+      description: >
+        `Measurement.host` — where the client ran, precisely enough to go back to it: an
+        address, a name, or both.
+      placeholder: "192.168.10.36 (argus-bench)"
+    validations:
+      required: true
+
+  - type: input
+    id: medium
+    attributes:
+      label: Link
+      description: >
+        `Measurement.medium` — what ran between that host and the CPU, with the median RTT
+        if you know it. Leaving this out is the specific omission that cost this project a
+        published claim: a transport conclusion that was a property of one Wi-Fi link.
+      placeholder: "wired, 3.64 ms median RTT"
+    validations:
+      required: true
+
+  - type: input
+    id: samples
+    attributes:
+      label: n
+      description: >
+        `Measurement.samples` — how many observations the answer rests on. `1` is a fine
+        answer for "this end code came back"; a percentile without its n cannot be given an
+        error bar by a reader. Leave blank when a count is not what the claim rests on.
+      placeholder: "300"
+    validations:
+      required: false
+
+  - type: dropdown
+    id: what-it-touches
+    attributes:
+      label: What this would change
+      description: Best guess is fine; we will work it out in the thread.
+      multiple: true
+      options:
+        - "a device range (ranges_iqf.tsv / ranges_iqr.tsv)"
+        - "a point limit (limits.tsv)"
+        - "an end code (end_codes.tsv)"
+        - "a model code (model_codes.tsv)"
+        - "a profile capability"
+        - "an open ambiguity (ambiguities.tsv, an A-... key)"
+        - "a row of docs/unverified.md"
+        - "a figure in docs/hardware.md"
+        - "not sure"
+    validations:
+      required: true
+
+  - type: input
+    id: ambiguity-key
+    attributes:
+      label: Ambiguity key, if this closes one
+      description: >
+        `aslmp ambiguities` prints the table, each row with the experiment that would
+        settle it. If you ran one of those probes, name its key.
+      placeholder: "A-ZR-RADIX"
+    validations:
+      required: false
+
+  - type: textarea
+    id: evidence
+    attributes:
+      label: The evidence, as your tools printed it
+      description: >
+        Whatever you have: `aslmp identify`, `aslmp capabilities <key>`,
+        `aslmp verify-ranges HOST --profile KEY --python` (which emits a paste-ready
+        `with_ranges()` call), `aslmp.testing.run_conformance`, `aslmp proxy` frames, or
+        raw hex. Unedited output is worth more than a summary of it.
+      render: text
+    validations:
+      required: true
+
+  - type: checkboxes
+    id: confirmations
+    attributes:
+      label: Before you post
+      options:
+        - label: >
+            Nothing was written to a machine that can move something, and I did not issue
+            remote RUN/STOP/PAUSE/RESET/Latch Clear on a CPU I could not see.
+          required: true
+        - label: >
+            The CPU model and firmware above are the ones this observation came from, not
+            the family or a sibling unit.
+          required: true

aslmp-0.1.0/.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,63 @@
+<!--
+Thank you. CONTRIBUTING.md has the long version of everything below; this is the short
+list that gets a change merged. Delete the sections that do not apply, but do not delete
+the provenance section if your diff touches a number.
+-->
+
+## What this changes, and why
+
+<!-- One paragraph. If it is a fix, say what the wrong behaviour was, not just what the
+     new behaviour is. -->
+
+## Checks
+
+Run all three locally — CI runs them on 3.11, 3.12 and 3.13 across Linux, Windows and
+macOS, and the matrix exists because a bug in this library was visible on exactly one of
+those nine cells.
+
+- [ ] `python -m ruff check src tests tools bench`
+- [ ] `python -m mypy`
+- [ ] `python -m pytest tests -q`
+
+## Does this touch a hardware claim?
+
+A hardware claim is any number, limit, range, end code, capability or behaviour that is
+asserted about real silicon — in a `.tsv`, in a docstring, in a doc, in a comment, or in
+a test's expected value. **This project does not accept one without its conditions.**
+Two published claims have been withdrawn here, and both were prose figures whose
+conditions were never written down.
+
+If your diff has one, fill this in; if it does not, write "no hardware claim" and move on.
+
+- **CPU model:**
+- **Firmware version:**
+- **Date measured (ISO):**
+- **Host:** <!-- where the client ran; an address, a name, or both -->
+- **Link:** <!-- wired / Wi-Fi, with median RTT if known -->
+- **n:** <!-- samples behind the figure, or "not a sample-based claim" -->
+
+- [ ] The claim is expressed as a `Measurement(...)` / `Evidence.measured(...)`, not as a
+      bare string, so the provenance and the source cannot drift apart.
+- [ ] Provenance is `LIVE` only where silicon was actually observed. A manual reading is
+      `MANUAL`; a value carried across from a sibling model is `INFERRED`, and says so.
+- [ ] If this converts an unverified row to a measured one, `docs/unverified.md` was
+      updated in the same commit. That page is billed as complete and a test enforces it.
+
+## Everything else
+
+- [ ] No new runtime dependency. The package has zero, deliberately: the wheel has to
+      install on a Jetson's aarch64 and on a plant PC with no compiler.
+- [ ] Nothing retries, clamps, substitutes a default, or returns a stale value. An
+      AST-level test enforces this over the whole package; if you had to work around it,
+      say so here rather than widening the exemption.
+- [ ] No new path from the CLI to remote RUN / STOP / PAUSE / RESET / Latch Clear. A
+      shell history is not an interlock, and a test walks the AST of `aslmp/tools` to
+      prove there is no such path.
+- [ ] Public surface changes are reflected in `aslmp.__all__` and `CHANGELOG.md`.
+- [ ] If this makes an unverified path look verified, or reads as a promise about safety,
+      certification or conformance, it does not go in. This library is not a safety
+      system, holds no conformance certification, and has no affiliation with Mitsubishi
+      Electric or the CC-Link Partner Association.
+
+By opening this pull request you are offering the contribution under the project's
+Apache-2.0 licence (see section 5 of `LICENSE`).

aslmp-0.1.0/.github/dependabot.yml

@@ -0,0 +1,25 @@
+# GitHub Actions only, and that is not an oversight.
+#
+# `aslmp` has zero runtime dependencies -- deliberately and load-bearing: the wheel has
+# to install on a Jetson's aarch64 and on a locked-down plant PC with no compiler and no
+# proxy to PyPI's transitive graph. So there is no `pip` ecosystem entry here, because
+# there is nothing in it to watch. The `dev` extra (pytest, hypothesis, mypy, ruff) is
+# declared as unpinned floors rather than pins, so a bump would have nothing to change;
+# CI installs whatever is current on each run, which is the honest way to find out that a
+# new mypy disagrees with us.
+#
+# The actions in `.github/workflows/` are pinned by major version, which is the one place
+# this repository does carry a supply chain -- a workflow action runs with a checkout of
+# our source and, in publish.yml, beside an OIDC token.
+
+version: 2
+
+updates:
+  - package-ecosystem: github-actions
+    directory: "/"
+    schedule:
+      interval: weekly
+    commit-message:
+      prefix: "ci"
+    labels:
+      - dependencies

aslmp-0.1.0/.github/workflows/ci.yml

@@ -0,0 +1,111 @@
+# The three checks this project ships under, on every interpreter and every OS it claims.
+#
+# Why the matrix is nine jobs and not one
+# ---------------------------------------
+# This project shipped a real bug that exactly one cell of this matrix would have caught.
+# `time.monotonic()` is backed by `GetTickCount64()` on Windows before CPython 3.13 and
+# steps at 15.625 ms, so on the oldest interpreter this package claims, on Windows, every
+# stamp it took landed on a ~16 ms grid: a 6 ms round trip was recorded as 0.0 or 16.0.
+# Measured 2026-09-12 on Python 3.11.15, Windows 11, against `perf_counter_ns` on the same
+# machine and the same sleep. It was invisible during development, which happens on 3.13,
+# where `monotonic` is `QueryPerformanceCounter` and resolves to 100 ns; it surfaced only
+# when the library was driven from a 3.11 environment. The fix is `src/aslmp/_clock.py`.
+#
+# "Latency as data" is this library's whole argument, so a quantised latency figure is
+# worse than an absent one. A single-version, single-OS CI would not have found that and
+# will not find the next one. The matrix is here for that reason and not for tidiness.
+#
+# Note that `mypy` pins `python_version = "3.11"` in `pyproject.toml`, so the interpreter
+# axis does not change what it type-checks -- the OS axis does, wherever behaviour is
+# platform-conditional, and that is the half of this matrix that earns its keep for mypy.
+
+name: CI
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+concurrency:
+  group: ci-${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: true
+
+jobs:
+  checks:
+    name: ${{ matrix.os }} / Python ${{ matrix.python-version }}
+    runs-on: ${{ matrix.os }}
+
+    # A healthy cell finishes in about two minutes. This bound is here because four
+    # cells of this matrix once sat INSIDE the pytest step for fourteen minutes and were
+    # still going when an unrelated push happened to cancel the run (2026-09-24, commit
+    # d78ef84: macos/3.12, macos/3.13, ubuntu/3.12 and windows/3.12 hung while
+    # windows/3.13 passed the same step in 109 s). Nothing stopped them but that
+    # accident. GitHub's default job timeout is 360 minutes, so each of those cells was
+    # entitled to six hours, and a macOS minute bills at ten times a Linux one.
+    #
+    # Fifteen minutes is roughly seven times the honest run and still bounds a hung
+    # macOS cell to about a dollar instead of twenty-two.
+    timeout-minutes: 15
+    strategy:
+      # Never fail fast. The point of the matrix is to see WHICH cells disagree; a
+      # cancelled run hides exactly the pattern that identifies a clock or a path bug.
+      fail-fast: false
+      matrix:
+        os: [ubuntu-latest, windows-latest, macos-latest]
+        python-version: ["3.11", "3.12", "3.13"]
+
+    defaults:
+      run:
+        # bash on all three runners, so the quoting in these steps is written once.
+        shell: bash
+
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-python@v7
+        with:
+          python-version: ${{ matrix.python-version }}
+          # There is nothing to lock -- this package has zero runtime dependencies -- but
+          # the dev extra pulls a toolchain on every one of nine cells, and two of those
+          # runners bill by the minute.
+          cache: pip
+          cache-dependency-path: pyproject.toml
+
+      - name: Install
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install -e ".[dev]"
+
+      # Hardware tests are excluded on purpose, and this step says so rather than
+      # leaving it to the marker. tests/hardware/ is gated on ASLMP_TEST_HOST and drives
+      # a real FX5U: it writes to scratch registers, and tests/hardware/
+      # test_remote_control.py issues Remote STOP, which halts a CPU. A CI runner must
+      # never be able to reach a PLC, so the variable is not set here and must not be
+      # added as a repository or environment secret.
+      - name: Assert the hardware gate is not set
+        run: |
+          if [ -n "${ASLMP_TEST_HOST:-}" ]; then
+            echo "ASLMP_TEST_HOST is set in CI. Hardware tests write to a real PLC and"
+            echo "can halt a CPU. Remove it from the repository/environment settings."
+            exit 1
+          fi
+
+      - name: ruff
+        run: python -m ruff check src tests tools bench
+
+      - name: mypy --strict
+        run: python -m mypy
+
+      # `-m "not hardware"` is belt and braces beside the ASLMP_TEST_HOST gate: the
+      # marker is the declared contract, the missing variable is what actually makes the
+      # tests skip, and neither one alone is worth relying on for something that can stop
+      # a machine.
+      # `faulthandler_timeout` in pyproject.toml is what makes a hang here legible: the
+      # stacks land in this step's log about a minute in, long before `timeout-minutes`
+      # kills the job, so the log names the test and the await instead of just stopping.
+      - name: pytest
+        run: python -m pytest tests -q -m "not hardware" --durations=10

aslmp-0.1.0/.github/workflows/publish.yml

@@ -0,0 +1,94 @@
+# Build a release and publish it to PyPI with trusted publishing (OIDC).
+#
+# There is no API token anywhere in this file and there must never be one. Trusted
+# publishing mints a short-lived, workflow-scoped credential at run time; a long-lived
+# token in a repository secret is a credential that can publish `aslmp` from anywhere,
+# forever, and this package installs on machines that talk to PLCs.
+#
+# WHAT THE OWNER STILL HAS TO DO -- none of it can be done from this repository
+# ----------------------------------------------------------------------------
+# 1. On PyPI, add a *pending* trusted publisher before the first release
+#    (https://pypi.org/manage/account/publishing/), because the project name is not
+#    registered yet -- README.md says so in its Install section. The four fields are:
+#        PyPI project name:  aslmp
+#        Owner:              AcaysiaChem
+#        Repository name:    aslmp
+#        Workflow name:      publish.yml
+#        Environment name:   pypi
+#    All five must match exactly, including the environment, or the publish step is
+#    rejected with an OIDC error rather than a permissions one.
+# 2. Create a GitHub environment named `pypi` (Settings -> Environments) and, if you
+#    want a human in the loop, add yourself as a required reviewer there. That is the
+#    only gate between "someone pushed a release" and "a new aslmp is on PyPI".
+# 3. Publish a GitHub release whose tag is the version, e.g. `v0.1.0`. This workflow
+#    refuses to publish if that tag disagrees with `src/aslmp/_version.py`.
+#
+# Two jobs on purpose: `build` needs no privileges at all, and `publish` holds the OIDC
+# token and runs nothing but the upload. Nothing that touches the internet or the
+# project's own code executes in the job that can sign.
+
+name: Publish
+
+on:
+  release:
+    types: [published]
+
+permissions:
+  contents: read
+
+jobs:
+  build:
+    name: Build sdist and wheel
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+
+      - uses: actions/setup-python@v7
+        with:
+          python-version: "3.12"
+
+      - name: Check the tag against src/aslmp/_version.py
+        run: |
+          set -euo pipefail
+          version=$(python -c "import runpy; print(runpy.run_path('src/aslmp/_version.py')['__version__'])")
+          tag="${GITHUB_REF_NAME#v}"
+          echo "tag=$tag  _version.py=$version"
+          if [ "$tag" != "$version" ]; then
+            echo "Release tag $GITHUB_REF_NAME does not match __version__ $version."
+            echo "The version literal exists once, in src/aslmp/_version.py. Fix one of them."
+            exit 1
+          fi
+
+      - name: Build
+        run: |
+          python -m pip install --upgrade pip build twine
+          python -m build
+          python -m twine check --strict dist/*
+
+      - uses: actions/upload-artifact@v7
+        with:
+          name: dist
+          path: dist/
+          if-no-files-found: error
+
+  publish:
+    name: Publish to PyPI
+    needs: build
+    runs-on: ubuntu-latest
+    # The environment is half of the trusted-publisher match configured on PyPI, and it
+    # is where a required reviewer goes if you want one.
+    environment:
+      name: pypi
+      url: https://pypi.org/p/aslmp
+    permissions:
+      # The OIDC token. This is the only privilege this job has, and the only job that
+      # has it.
+      id-token: write
+    steps:
+      - uses: actions/download-artifact@v8
+        with:
+          name: dist
+          path: dist/
+
+      # `release/v1` is PyPA's own major-version ref for this action.
+      - uses: pypa/gh-action-pypi-publish@release/v1