vnnlib-test-solver 2.0.0__tar.gz

vnnlib_test_solver-2.0.0/.gitignore

@@ -0,0 +1,218 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+#   Usually these files are written by a python script from a template
+#   before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py.cover
+.hypothesis/
+.pytest_cache/
+cover/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .python-version
+
+# pipenv
+#   According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+#   However, in case of collaboration, if having platform-specific dependencies or dependencies
+#   having no cross-platform support, pipenv may install dependencies that don't work, or not
+#   install all needed dependencies.
+# Pipfile.lock
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+# uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+# poetry.lock
+# poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+# pdm.lock
+# pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+# pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# Redis
+*.rdb
+*.aof
+*.pid
+
+# RabbitMQ
+mnesia/
+rabbitmq/
+rabbitmq-data/
+
+# ActiveMQ
+activemq-data/
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#   JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#   be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#   and can be added to the global gitignore or merged into this file.  For a more nuclear
+#   option (not recommended) you can uncomment the following to ignore the entire idea folder.
+# .idea/
+
+# Abstra
+#   Abstra is an AI-powered process automation framework.
+#   Ignore directories containing user credentials, local state, and settings.
+#   Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#   Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#   that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#   and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#   you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+# Temporary file for partial code execution
+tempCodeRunnerFile.py
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+
+# Streamlit
+.streamlit/secrets.toml

vnnlib_test_solver-2.0.0/CHANGELOG.md

@@ -0,0 +1,252 @@
+# Version 2.0.0
+
+A breaking release, and every break in it is a client ruling rather than a change of
+mind here. Anything written against 1.0.0 needs all three of the following.
+
+**The command is renamed `vnnlib-test-solver` to `vnnlibTestSolver`**, and the
+configuration file it looks for in the working directory follows it to
+`vnnlibTestSolver.toml`. There is no alias for either old spelling. The distribution is
+still installed as `vnnlib-test-solver` and the import package is still
+`vnnlib_test_solver`; the three differ deliberately, because a distribution name is
+normalised to lower case by every installer that reads one and an import package cannot
+contain a dash at all.
+
+**There is no longer a default configuration.** Running with no `--config`, no
+`VNNLIB_TEST_SOLVER_CONFIG` and no `vnnlibTestSolver.toml` in the working directory is
+now an error, exiting 2 with nothing on standard output. It previously answered
+`unknown` for every query and reported a full set of capabilities. This applies to
+`--name` and `--version` as much as to `verify`: they are configured answers like any
+other. The reasoning is that a test solver must never give an answer nobody chose,
+because that is the one reply in the system indistinguishable from a deliberate one.
+
+**The `real` exemption is now a property of the whole query rather than of each
+declaration.** The standard exempts a query written in `real` from two of the three
+error conditions the verify command must report, and defines a real-valued query as one
+that uses that type exclusively. A query declaring `real` alongside any other type is
+therefore not exempt at all, including for its `real` variables, where previously each
+such variable was exempt on its own. A query written entirely in `real` is exempt in
+full, exactly as before. A configuration wanting a mixed query to answer names `real` in
+its soundness claim, which is the same explicit claim every other element type already
+needed. Mixing element types is still not itself refused.
+
+Also in this release, and neither of them breaking:
+
+* Reporting the `real` element type no longer warns that it is unclaimed. The standard
+  makes `real` the answer a solver gives precisely when it cannot promise sound
+  reasoning over floating point, so a configuration reporting it alone and claiming
+  nothing was being warned at for following the standard's own advice. Reporting
+  `float32` or `float64` without the matching claim still warns, which is the case the
+  clause actually names.
+* The exit codes are unchanged and are now confirmed conformant rather than assumed to
+  be. The standard says only that zero means the solver ran and terminated normally,
+  `unsat` and `timed-out` included, and is deliberately not opinionated about what any
+  non-zero value means.
+
+**This version is the first published to PyPI**, so it installs with `pip install
+vnnlib-test-solver` instead of from a clone of the repository. Nothing about the solver
+changed to make that true and no behaviour here depends on how it was installed; the
+distribution keeps the name it already had, and the command it installs is still
+`vnnlibTestSolver`.
+
+**Still not in this release.** The three limitations listed under *Not in this release* in
+the 1.0.0 entry below all carry forward unchanged: serialised assignments are not written,
+a red continuous-integration result does not mechanically block a merge, and assignment
+values are not checked beside a result other than `sat`. None of them was resolved here.
+
+---
+
+# Version 1.0.0
+
+The first release.
+
+A configurable test solver for the VNN-LIB standard: it implements the command-line
+interface of chapter 5 of the standard and answers entirely from a TOML configuration
+file, performing no verification of its own. It exists so that a tool driving VNN-LIB
+solvers can be tested against a solver whose every response it controls.
+
+What a caller gets from this release:
+
+* Both global options, `--name` and `--version`, answered from configuration.
+* The `supports` command answering all eleven of the capabilities the standard makes
+  mandatory, in the four response shapes it defines.
+* The `verify` command accepting the full invocation of section 5.3 and returning any of
+  `sat`, `unsat`, `unknown` or `timed-out`, chosen by matching the query file's name
+  against configured rules.
+* A configurable delay, so that a caller's own timeout handling can be exercised against
+  a solver that answers on the caller's deadline rather than one that genuinely takes
+  minutes.
+* The satisfying assignment of section 5.3.1 in the command-line format, printed from
+  configured values and the query file's own declarations, and compared byte for byte
+  against the standard's worked example.
+* All three of the error conditions section 5.3.2 requires, each distinguishable from
+  the others and checked in the order the standard lists them.
+* Four controls that make the solver misbehave on request - noise on `stderr`, an
+  arbitrary exit status, deliberately malformed output, and abnormal termination - so
+  that a caller can exercise its own handling of a solver behaving badly.
+* Output guaranteed to be deterministic and `LF`-terminated on every platform, with
+  results on `stdout` and everything else on `stderr`.
+
+Installing needs no compiler and no build tooling on Linux `x86_64`, macOS and Windows.
+There is no `aarch64` Linux wheel for the pinned parser dependency, so that one platform
+builds it from source; the readme's requirements section has the detail.
+
+## Not in this release
+
+* **Serialised assignments.** Section 5.3.1's optional `.pb` `TensorProto` output is not
+  written. The standard requires the option only of a solver that reports supporting it,
+  and this solver reports `false`; the option is still accepted, and says on `stderr`
+  that nothing was written rather than exiting zero having silently done nothing. The
+  command-line assignment format, which the standard makes the default and requires of
+  every solver, is implemented.
+* **Enforcement of the continuous integration result.** The suite runs on nine platform
+  and version combinations on every pull request, but a red result does not block a
+  merge. That is branch protection rather than a workflow, and it needs repository
+  administration this team does not hold.
+* **A check on assignment values beside a result other than `sat`.** A value array of the
+  wrong length, or one naming a variable the query does not declare, is refused beside
+  `result = "sat"` and accepted in silence beside any other result, because values that
+  will never be printed are never measured. Documented rather than corrected: changing it
+  moves an exit code that other code in this project already tests against.
+
+## How this release was built
+
+Everything below is the record of the work, newest first. None of it describes a change
+to a previously published version, because there is not one - 0.1.0 was never tagged and
+never published. It is kept because what was decided, and why, is worth more than a
+summary of it.
+
+Each entry describes the package as it stood when that piece of work landed. An entry
+saying something is not implemented yet has been overtaken by one above it; the Version
+1.0.0 entry above is what 1.0.0 actually does.
+
+* Added continuous integration. The test suite now runs on Ubuntu, macOS and Windows
+  against Python 3.9, 3.11 and 3.13 on every pull request, with `fail-fast` disabled so
+  that one platform's failure does not hide another's. Two of the defects found in this
+  package so far are invisible on Linux, and the declared Python floor of 3.9 had never
+  been executed anywhere until now.
+* Added a job that installs the package into a container with no compiler, no CMake and
+  no pybind11 present, and which refuses to run at all if one of them is on the path. It
+  also forbids a source build of the parser, so the pure-Python claim cannot be satisfied
+  by a machine that happened to be able to compile something.
+* Added a byte-for-byte conformance suite comparing standard output against eleven
+  committed expected-output files: the standard's own worked example, one per verify
+  result, the four capability response shapes transcribed from the standard's own
+  examples, and the two cases where injected output replaces the answer. Every comparison
+  is made on raw bytes, and a mismatch names the line that differs rather than printing
+  two blobs.
+* Added tests asserting that five consecutive runs of every command that writes to
+  standard output produce identical bytes. The five runs use five different hash seeds,
+  so an unordered collection reaching the output fails every time rather than most of the
+  time.
+* Added a self-test, selectable with `-m contract`, asserting that the published
+  interface is exactly what is documented: the global options, both commands and their
+  options, the eleven capability flags, every configuration file key, the configuration
+  discovery order and the exit codes. It checks both directions - that everything
+  documented exists, and that nothing undocumented exists.
+* Documented, without changing it, that a rule's assignment values are only checked
+  against the query when that rule answers `sat`. A value array of the wrong length, or a
+  name the query does not declare, is refused beside `result = "sat"` and accepted in
+  silence beside `result = "unsat"`. This has been true since assignments were added and
+  had simply never been stated.
+* Corrected the description of the `verify` command in the README, which said two of the
+  standard's three error conditions were not implemented. All three have been implemented
+  since the previous release, and the same file documented them at length two sections
+  further down.
+* Added regression tests asserting what the solver deliberately does not reject. The
+  standard leaves anything outside its three named error conditions to the solver's
+  discretion, and a conformance baseline that invents a fourth rejection teaches that
+  invented rule to every test written against it. Covered: a query mixing the `real`
+  element type with another one, two networks declared under the same name, hidden nodes,
+  comments and irregular whitespace, a mapped model file that does not exist or is not an
+  ONNX file at all, and a query file with any name or none. No behaviour changed.
+* The four failure-injection controls now do something. `stderr` writes the configured
+  noise before the answer and before any delay, `exit_code` returns the configured status,
+  `raw_stdout` replaces standard output entirely, and `crash` terminates the process
+  abnormally after the output has been written and flushed. Each was accepted and
+  validated from the first release and had no effect until now.
+* Added a top-level `[injection]` table carrying the same four controls and applying to
+  whichever command runs. A rule is selected by matching the query file's name and the
+  `supports` command has no query file, so nothing hanging off a rule could reach a
+  capability response, and a malformed one was not producible at all. Where a rule and the
+  table both set a control, the rule wins for that control alone.
+* Nothing is injected into a run that is refused. A configuration mistake, a usage mistake
+  and each of the standard's error conditions keep their own exit code and write nothing
+  to standard output, so the solver can still report its own errors.
+* Fixed: `exit_code` is now refused unless it is between 0 and 255. A process exit status
+  carries eight bits on a Unix-like system, so `exit_code = 256` reached the caller as
+  `0` - a run configured to fail reporting that it had succeeded. Invisible on Windows,
+  where the whole value survives. The refusal names what the value would have become.
+* Setting `crash` and `exit_code` in the same table is refused, because a process that
+  terminates abnormally reports no exit status and only one of the two can happen. Set on
+  a rule and in the table respectively, the rule's wins.
+* Added the second and third error conditions the standard requires of `verify`. The
+  element types the supplied model files expose must not disagree with the types the query
+  declares, and a query declaring a type the solver cannot analyse soundly is refused
+  unless the user consented by declaring it `real`. Both write nothing to `stdout`, exit
+  `1`, and carry messages distinct from each other and from the model-mapping condition,
+  so a caller can tell which one it triggered without matching on wording. All three are
+  checked in the order the standard lists them.
+* Added `[rules.model_element_types]`, a table keyed by variable name stating what the
+  supplied model files expose. Nothing here opens a model file, so this is the only source
+  the element-type condition can have; the query supplies the declared types it is compared
+  against. A variable the table does not name is taken to match, and a name the query does
+  not declare is a configuration error rather than one of the standard's conditions.
+* `[soundness] sound-for` now drives an error as well as a warning. A configuration with no
+  `[soundness]` table is not checked at all, because reading silence as a claim of total
+  unsoundness would make every such configuration refuse every query; an explicitly empty
+  `sound-for` is a claim, and refuses everything not declared `real`.
+* A declaration written in `real` is exempt from both new conditions, applied to each
+  declaration on its own rather than to the query as a whole. The standard describes a
+  real-valued query as using `real` exclusively, but the query parser accepts a query
+  mixing `real` with another element type, so a decision was needed and refusing such a
+  query would have invented a rejection the standard leaves to solver discretion.
+* The packaged default configuration now reports and claims soundness over `int32`.
+  Without it the default refused the standard's own worked example as soon as a model file
+  was mapped, since that example declares an `int32` variable.
+* Added the `verify` command, as far as its result line: the query file path, a
+  repeatable `--network <name>=<path>`, `--timeout` in whole seconds, and
+  `--serialise-assignments`. `--assignments` is accepted alongside the latter, because
+  section 5.3 spells the same option both ways. The result is the first line of `stdout`
+  and is one of `sat`, `unsat`, `unknown` or `timed-out`. Variable assignments for a `sat`
+  result are not implemented yet, and the query file is not read at all.
+* Which result a query receives is decided by the `[[rules]]` array. The first rule whose
+  `match` pattern matches the query file's **name** wins; patterns are compared against the
+  name alone, case sensitively on every platform. A query that no rule matches is an error
+  rather than a silently chosen default, and the message names the file and every pattern
+  it tried.
+* A rule's `delay_seconds` now interacts with `--timeout`. A delay longer than the timeout
+  waits out the timeout and answers `timed-out`, so a caller's own deadline handling can be
+  exercised against a solver that reliably runs long. A delay equal to the timeout answers
+  normally, and an absent `--timeout` is not a timeout of zero.
+* Fixed: an empty query path is refused. `verify ""` was accepted, matched the catch-all
+  rule pattern, and answered for a file that cannot exist.
+* Fixed: `--timeout` and a rule's `delay_seconds` are bounded. Above roughly 68 years the
+  wait itself raises, so a large value reached the caller as an unhandled traceback rather
+  than a message. The bound is a fixed constant rather than the platform's own ceiling, so
+  a configuration that loads on one machine cannot raise on another.
+* `--serialise-assignments` now reports on `stderr` that assignment files are not written
+  yet. It was previously accepted and silently ignored, which to a caller testing
+  serialisation was indistinguishable from success.
+* Fixed: `stdout` is written as bytes and uses `LF` line endings on every platform. On
+  Windows every command emitted `CRLF`, which made recorded output impossible to compare
+  byte for byte between platforms and left a trailing carriage return inside every value a
+  consumer read by splitting on newlines.
+* Fixed: a configuration value that would corrupt the shape of a response is refused when
+  the file loads rather than emitted. An operator name containing whitespace was the
+  damaging case, because it produced output that parsed cleanly and meant something else:
+  an operator named `Conv Relu` was read back as the operator `Conv` supporting an element
+  type called `Relu`. Empty and whitespace-bearing version strings, and line breaks in the
+  solver name or version, are refused for the same reason. The failure-injection keys are
+  deliberately exempt, since producing unparseable output is their purpose.
+* Added the `supports` command, answering all eleven mandatory capabilities of the
+  standard's section 5.4 from configuration, in the four response shapes it defines.
+  `capabilities` is accepted as an undocumented alias, because section 5.1 names the
+  command that way while section 5.4 defines it as `supports`.
+* A configuration reporting an ONNX element type it does not also claim sound analysis
+  over now warns on `stderr`, per section 5.4.1.
+* Added the installable package: console entry point, configuration discovery across four
+  sources, schema validation, and the `--name` and `--version` global options.
+* Added `.gitattributes` to force LF line endings and mark golden/fixture files
+  binary, so line-ending conversion can never corrupt a byte-exact comparison.
+* Wrote the first `README.md`, replacing the two-line placeholder the repository was
+  created with.

vnnlib_test_solver-2.0.0/CONTRIBUTING.md

@@ -0,0 +1,186 @@
+# Contributing
+
+This repository implements the VNN-LIB 2.0 command-line interface (Chapter 5 of the
+standard) as a configurable test solver.
+
+## Setting up a working copy
+
+```bash
+git clone <repo-url>
+cd VNNLIB-Test-Solver
+python -m venv .venv
+source .venv/bin/activate      # Windows: .venv\Scripts\activate
+pip install -e ".[dev]"
+```
+
+The `[dev]` extra pulls in the test, lint and type-checking tools alongside the package
+itself. `pip install .` on its own is enough to run the solver, but not enough to run its
+test suite - if `pytest` cannot be found, this is why.
+
+Python 3.9 or later. This package is pure Python, but its one dependency is a compiled
+extension and there is no Linux `aarch64` wheel for the pinned version. On Linux
+`x86_64`, macOS and Windows an install needs no compiler, CMake or other build tooling;
+on arm64 Linux it builds the parser from source and does need them. The readme's
+requirements section carries the platform table.
+
+## The parser dependency
+
+`vnnlib` is confined to a single module, which is the only file permitted to import it.
+Everything crossing out of that module is a plain string, integer or tuple - no parser
+object and no name from the parser's vocabulary reaches the rest of the package. That
+confinement is what makes the dependency reversible: were this package ever required to
+be standalone, one file would change and every other module would keep its interface.
+
+## Running the checks
+
+```bash
+python -m pytest -q             # the test suite
+python -m pytest -q -m contract # the published interface, on its own
+ruff check .                    # lint
+ruff format --check .           # formatting
+mypy src/                       # type checking
+```
+
+`ruff format --check` is not the same command as `ruff check`: the first looks at
+formatting and the second does not, so running one is not running the other.
+
+`vnnlibTestSolver --version` should also work once installed. The test suite shells out
+to that installed console script rather than importing the package, because what this
+project delivers is a binary, so a suite that called into Python directly would prove
+nothing about what happens after `pip install`.
+
+## What runs on a pull request
+
+`.github/workflows/buildAndTest.yml` runs the suite on Ubuntu, macOS and Windows against
+Python 3.9, 3.11 and 3.13 - nine combinations, with `fail-fast` off so one platform's
+failure does not hide another's. Two further jobs run alongside it: lint, formatting and
+type checking; and an installation into a container with no compiler, no CMake and no
+pybind11 present, which is how the pure-Python claim is proven rather than asserted.
+
+A failing check is visible on the pull request but does not mechanically prevent a merge,
+because branch protection is not configured on this repository. Read the checks before
+merging.
+
+## How correctness is established
+
+This package is a conformance baseline: other people's tests measure against its output.
+If it is wrong, every one of those tests is measuring against a broken ruler and still
+passing. That makes "the suite is green" a weaker claim here than it is in most projects,
+and the practices below exist to close the gap.
+
+### The suite tests the delivered artifact
+
+Tests shell out to the installed console script rather than importing the package. What
+this project ships is a binary, so a suite that called into Python directly would prove
+nothing about what happens after `pip install` - it would not catch a broken entry point,
+a missing dependency, or packaging metadata that disagrees with the code.
+`tests/test_packaging.py` checks the installed distribution specifically.
+
+### Output is compared as bytes, never as text
+
+`tests/golden/` holds eleven expected-output files: the standard's own worked example, one
+per `verify` result, the four capability response shapes, and the two cases where injected
+output replaces the answer. Every comparison is on raw bytes, so line endings, spacing
+inside `[2,2]` and trailing newlines are all part of what is asserted.
+`tests/test_output_bytes.py` reads streams as bytes rather than decoded text, because a
+decoded comparison silently hides exactly the platform differences most worth catching.
+
+**Nothing regenerates the golden files.** If a change makes one fail, the question is which
+of the two is wrong, and the answer belongs in the pull request description line by line.
+An expected-output file that nobody has read is not a specification, it is a snapshot of
+whatever the code did last.
+
+`tests/test_determinism.py` runs the same input repeatedly and requires the bytes to be
+identical, which is what stops a set iteration or a timestamp reaching output unnoticed.
+
+### Tests assert what is *not* rejected
+
+Section 5.3.2 makes three things errors and leaves everything else to the solver's
+discretion. A package that quietly grew a fourth error condition would break callers
+relying on that discretion, and no ordinary test would notice, because nothing was
+asserting the absence. `tests/test_not_over_policed.py` exists to hold that line: it feeds
+in unusual but legal queries and requires them to be answered rather than refused.
+
+### A claim is verified or it is labelled an assumption
+
+Where the standard is silent or contradicts itself, this package implements the most
+conservative reading and says so, rather than encoding a guess as though it were settled.
+The inconsistencies found while implementing Chapter 5 were reported upstream -
+[VNNLIB-Standard#179](https://github.com/VNNLIB/VNNLIB-Standard/issues/179) and
+[VNNLIB-Standard#181](https://github.com/VNNLIB/VNNLIB-Standard/issues/181) - rather than
+resolved privately, so that the next implementer meets a documented question instead of
+rediscovering it.
+
+### Claims about the build are proven, not asserted
+
+"Pure Python, no toolchain needed" is easy to believe on a machine that has a compiler
+sitting on its path. The container job refuses to run at all if `cc`, `gcc`, `g++`,
+`clang`, `make` or `cmake` is present, and forbids pip from building the parser from
+source, so it cannot pass for the wrong reason. The platform where that claim does *not*
+hold - Linux `aarch64` - is named in the readme rather than left to be discovered.
+
+### When reviewing a test, check it can fail
+
+A check comparing two things to each other rather than to an expected value passes when
+both are broken. This has happened here: two spellings of one command were compared to
+each other, and with no capabilities configured both failed identically, so the check
+passed while measuring nothing. Before trusting a new test, break the thing it names and
+confirm it goes red.
+
+## Making a release
+
+1. Update the version in `pyproject.toml` and `src/vnnlib_test_solver/__init__.py`.
+   Tests assert that both agree with the installed distribution, so missing one fails
+   the suite rather than shipping.
+
+2. Add a row to the version compatibility table in `README.md`.
+
+3. Add the version and its changes to `CHANGELOG.md`.
+
+4. Merge to `main`, then tag the merge commit once its checks are green:
+
+   ```bash
+   git checkout main && git pull
+   git tag -a v1.0.0 -m "Version 1.0.0"
+   git push origin v1.0.0
+   ```
+
+5. Create a Release on GitHub against that tag, using the changelog entry as its
+   description. Publishing the Release runs `Build-and-Deploy`, which builds the source
+   distribution and the wheel, checks them, and uploads both to PyPI.
+
+To rehearse an upload first, run `Build-and-Deploy` by hand and choose TestPyPI. It
+builds and checks exactly as the real run does, and uploads to an index nobody installs
+from.
+
+To see what would be built without uploading anything:
+
+```bash
+pip install build twine
+python -m build
+twine check --strict dist/*
+python .github/scripts/check_sdist.py
+```
+
+`build` and `twine` are deliberately not in the `dev` extra. They inspect the package
+rather than forming part of it, and what this package installs is a constraint it is
+held to.
+
+### What an upload commits you to
+
+A version number on PyPI can never be reused. Deleting a release does not free it, and
+yanking one hides it from resolvers while leaving the files downloadable by anyone who
+asks for that version exactly. There is no correcting a release afterwards, only
+releasing again with a higher number.
+
+Two checks therefore run before every upload and both refuse it outright rather than
+warning. One compares the source distribution against `git ls-files` and fails if it
+carries a single file this repository does not track. The other fails if the version
+built disagrees with the tag the Release names, which is what a Release created against
+an older tag looks like.
+
+The first is not a formality. The build backend ships whatever is in the project
+directory unless told otherwise, and the files kept out of this repository through
+`.git/info/exclude` are invisible to it, because that file is local to one clone. Built
+without the explicit list in `pyproject.toml`, this package produced a 1.3 MB archive
+carrying working notes, meeting minutes and a copy of the standard.

vnnlib_test_solver-2.0.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 VNNLIB
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.