htpolynet 2.3.1__tar.gz → 2.5.0__tar.gz

htpolynet-2.5.0/.claude/skills/htpolynet/SKILL.md

@@ -0,0 +1 @@
+../../../src/htpolynet/resources/claude/SKILL.md

htpolynet-2.5.0/.github/workflows/docker.yml

@@ -0,0 +1,72 @@
+name: Build and push Docker image
+
+on:
+  push:
+    tags:
+      - "v*"
+      - "d*"
+  schedule:
+    # Rebuild weekly (Monday 03:00 UTC) to pick up latest Gromacs/AmberTools
+    - cron: '0 3 * * 1'
+
+jobs:
+  docker:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          # The default image.  conda-forge's preferred linux-64 Gromacs is the
+          # OpenCL build, which cannot drive NVIDIA devices; this image is
+          # CPU-only by design and stays the default so `docker run` on a
+          # laptop keeps working without pulling the CUDA toolkit.
+          - variant: cpu
+            gromacs_build: ""
+            cuda_override: ""
+            tag_prefix: ""
+          # The CUDA image.  gromacs=*=nompi_cuda* depends on the __cuda
+          # virtual package, which conda synthesizes only where an NVIDIA
+          # driver is present -- so the solve fails on this runner unless
+          # CONDA_OVERRIDE_CUDA declares one.  That makes the image buildable
+          # here; it does NOT make it verifiable here.  Nothing in CI can
+          # confirm that mdrun actually offloads, so smoke-test a new CUDA
+          # image on real hardware before recommending it.
+          - variant: cuda
+            gromacs_build: "nompi_cuda"
+            cuda_override: "12.9"
+            tag_prefix: "cuda-"
+    steps:
+    - uses: actions/checkout@v4
+
+    - name: Log in to GitHub Container Registry
+      uses: docker/login-action@v3
+      with:
+        registry: ghcr.io
+        username: ${{ github.actor }}
+        password: ${{ secrets.GITHUB_TOKEN }}
+
+    - name: Compute tags
+      id: tags
+      run: |
+        if [ "${{ matrix.variant }}" = "cuda" ]; then
+          moving="ghcr.io/cameronabrams/htpolynet:cuda"
+        else
+          moving="ghcr.io/cameronabrams/htpolynet:latest"
+        fi
+        printf 'tags<<EOF\n%s\nghcr.io/cameronabrams/htpolynet:%s%s\nEOF\n' \
+          "$moving" "${{ matrix.tag_prefix }}" "${{ github.sha }}" >> "$GITHUB_OUTPUT"
+
+    - name: Build and push
+      uses: docker/build-push-action@v6
+      with:
+        context: .
+        file: docker/Dockerfile
+        push: true
+        build-args: |
+          HTPOLYNET_COMMIT=${{ github.sha }}
+          GROMACS_BUILD=${{ matrix.gromacs_build }}
+          CONDA_OVERRIDE_CUDA=${{ matrix.cuda_override }}
+        tags: ${{ steps.tags.outputs.tags }}

{htpolynet-2.3.1 → htpolynet-2.5.0}/CHANGELOG.md

@@ -7,6 +7,165 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [2.5.0] - 2026-08-26
+
+### Added
+
+- **The conversion a cyanate-ester run reports is now the conversion the
+  structure actually carries.**  The cure iterates on bond conversion --
+  bonds formed over bonds possible -- and that is the only number it printed.
+  But `postcure_repair` then dismantles every crosslinker that did not fill
+  all of its sites, so the structure leaving the repair stage contains only
+  *complete* crosslinkers, and the fraction of those is what an experiment
+  measures.  For a trifunctional crosslinker under random placement the
+  second number is roughly the cube of the first, so a run at a bond
+  conversion of 0.90 leaves a cyanate conversion near 0.73 -- and nothing
+  said so.  The repair stage now logs both figures side by side and writes
+  them, with the counts behind them, to `repair-summary.yaml` in the repair
+  directory.
+
+- **`CURE.controls.completion_bias`, an opt-in change to how bond candidates
+  are ranked.**  Candidates have always been ordered by pair separation
+  alone.  Separation is uncorrelated with how many bonds a crosslinker
+  already carries, and the downselection that follows admits at most one bond
+  per residue per iteration, so bonds spread evenly across every crosslinker
+  in the box instead of finishing any of them.  With `completion_bias: true`
+  the number of bonds already on the candidate's `B`-side residue becomes the
+  primary sort key and separation the tie-break within each group, so a
+  crosslinker with two of three sites filled is completed before an untouched
+  one is started.  Nothing else about the search changes: same radius growth,
+  same dragging and relaxation, same probability application, same cycle
+  handling.
+
+  This is a modelling option, not a fix, and it is **off by default** so that
+  every existing config and every shipped example behaves exactly as before.
+  Where a partly-reacted crosslinker is a stable species the old ranking is
+  the more faithful one; where it is a reactive intermediate -- a
+  cyclotrimerizing cyanate ester, whose triazine ring either closes or does
+  not -- the new one is.  Turning it on changes what `desired_conversion`
+  means physically: a config that reaches a crosslinker conversion of 0.76 at
+  `desired_conversion: 0.90` unbiased reaches about 0.90 biased, so runs
+  either side of the setting must be compared at matched crosslinker
+  conversion, not matched `desired_conversion`.
+
+  It also nearly empties the repair stage, which is worth having on its own
+  terms: repair has been seen to blow up at low conversion, where it places
+  hundreds of caps and transfers hundreds of fragments and the cap-placement
+  geometry produces atom overlaps that a step-0 minimization cannot recover
+  from.  Completing crosslinkers instead of decorating them leaves it almost
+  nothing to do.
+
+- **A CUDA image, published as `ghcr.io/cameronabrams/htpolynet:cuda`.**  The
+  only image until now installed conda-forge's default linux-64 Gromacs,
+  which is an OpenCL build; Gromacs no longer drives NVIDIA devices through
+  OpenCL, so that image cannot use a GPU at all.  The new tag installs
+  `gromacs=*=nompi_cuda*` from the same Dockerfile and can.
+
+  The CPU image remains `:latest` and remains the default, because the CUDA
+  build pulls in the CUDA toolkit and inflates the image substantially --
+  `docker run` on a laptop should not download a toolkit it cannot use.
+  Both tags are built by the same workflow on the same triggers, and both
+  carry the per-commit tag scheme (`:<sha>` and `:cuda-<sha>`).
+
+  `external.software.gpu_unusable_reasons()` needed no change: it already
+  reconciled detected hardware against what the gmx build can drive, so the
+  CUDA image simply starts passing checks the CPU image fails.
+
+  Verified on hardware, since nothing in CI can check this: on a Picotte
+  V100 node the image reports `GPU support: CUDA` where `:latest` reports
+  OpenCL, `htpolynet info` detects the device instead of calling it
+  `unusable`, and a complete `fetch-example 1` build ran every one of its
+  `gmx mdrun` steps with `-gpu_id 0`, using cuFFT for PME.  The CUDA 12.9
+  runtime in the image runs against that node's 12.4-era driver (550.127.05)
+  under CUDA minor-version compatibility, so a site does not need a
+  bleeding-edge driver to use the tag.
+
+### Changed
+
+- **Repair drivers now return a statistics dict rather than an operation
+  count**, and `htpolynet.repair.run_repair` returns `(total, stats)` rather
+  than a bare total.  This is what carries the crosslinker-conversion figures
+  out to the runtime for reporting.  Only affects code that calls a repair
+  driver directly; the `postcure_repair` config surface is unchanged.
+
+### Fixed
+
+- **The container documentation told users to give the image a GPU, which it
+  cannot use.**  `container-usage.rst` carried a "GPU support" section
+  walking through the NVIDIA Container Toolkit and a `deploy.resources`
+  block reserving nvidia devices, ending "htpolynet will detect the
+  available GPU(s) automatically at startup" -- and then, sixty lines later
+  in the Singularity section, correctly warned that the image's conda-forge
+  Gromacs is an OpenCL build and cannot drive NVIDIA devices at all.  The
+  page contradicted itself, and `README.md` repeated the wrong half with a
+  `docker run --gpus all` example.
+
+  Both now say the same thing: exposing a GPU to this image starts the
+  container and changes nothing about how it computes, so target CPU
+  partitions and do not hold a device another job could use.  The reason and
+  the detection behavior are stated once, under Docker, and the HPC warning
+  points at it for the `--nv`/`--gres=gpu` specifics.
+
+### Changed
+
+- `htpolynet setup-claude` is now discoverable where a new user will meet
+  it: the installation page and the README, rather than only the subcommand
+  reference.
+
+## [2.4.0] - 2026-08-25
+
+### Added
+
+- **`htpolynet setup-claude` installs the bundled Claude Code skill**, so it
+  reaches users who `pip install` or `conda install` htpolynet rather than
+  only those working inside a clone.  The skill previously lived at
+  `.claude/skills/htpolynet/`, which the tool finds only when the working
+  directory is the repository -- that is contributors, and not most users.
+  It now ships as package data and is copied to
+  `~/.claude/skills/htpolynet/SKILL.md` on request; `--skills-dir
+  ./.claude/skills` scopes it to one project instead, and `--force`
+  overwrites an existing copy after an upgrade.
+
+  Nothing happens at install time: installing the package never writes to
+  `~/.claude/`.  The repository's `.claude/skills/htpolynet/SKILL.md` is now
+  a symbolic link to the packaged file, so a clone and an install get the
+  same skill and the two cannot drift apart.
+
+  The skill itself was rewritten to stand alone.  It used to be a router --
+  its first instruction was to read
+  `docs/source/user-guide/building-a-system.rst`, a path that does not exist
+  for an installed user -- so it now carries the procedure inline and cites
+  Read the Docs once as the full reference.
+
+### Fixed
+
+- **The container image now reports the commit it was built from.**  A
+  published image had no way to say what code it contained: there is no git
+  in the image and no `.git` beside the installed package, so
+  `htpolynet info` fell back to the installed version -- which is right for
+  pip and conda and *misleading for the container*, because the weekly
+  scheduled rebuild builds from `main` HEAD and reports whatever
+  `pyproject.toml` last said.  An image built four commits past a release
+  claimed to be that release, and `:latest` is the default thing people
+  pull.  A user could pull `:latest`, trust the version string, and record
+  the wrong version in a methods section.
+
+  The build now passes the commit as a `HTPOLYNET_COMMIT` build argument,
+  the image carries it in its environment, and `htpolynet info` reports it
+  in preference to the version fallback.  A real git checkout still wins
+  over both, since it reflects the working tree including uncommitted
+  changes.  The container-usage guide explains why `:latest` moves and how
+  to pull by digest or per-commit tag when provenance has to be stateable
+  later.
+
+- The container-usage guide now distinguishes two habits that are easy to
+  conflate: **pulling once** gives a campaign a constant tool chain, while
+  **recording the digest** is what lets you state afterwards what that tool
+  chain was.  The image pins more than the htpolynet code -- Gromacs and
+  AmberTools come unpinned from conda-forge at build time, so two images
+  built days apart can carry different versions of either while running
+  identical htpolynet code.
+
 ## [2.3.1] - 2026-08-25
 
 ### Fixed

{htpolynet-2.3.1 → htpolynet-2.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: htpolynet
-Version: 2.3.1
+Version: 2.5.0
 Summary: Automated MD System Builder for Amorphous Network Polymers
 Project-URL: Source, https://github.com/cameronabrams/htpolynet
 Project-URL: Documentation, https://htpolynet.readthedocs.io/
@@ -67,21 +67,24 @@ pip install -e .
 
 Once installed, the user has access to the main ``htpolynet`` command.
 
+If you drive htpolynet with [Claude Code](https://claude.com/claude-code), install the bundled skill so the agent knows how to use it:
+```bash
+htpolynet setup-claude
+```
+This writes `~/.claude/skills/htpolynet/SKILL.md`; nothing is installed there unless you run it.
+
 IMPORTANT NOTES: The programs ``antechamber``, ``parmchk2`` and ``tleap`` from AmberTools must be in your path.  These can be installed using the ``ambertools`` package from ``conda-forge`` or compiled from source.  You also need Gromacs installed so ``gmx`` is in your path.  The examples show how to build input monomer structures using OpenBabel, so to use them you need ``obabel`` in your path as well.
 
 ## Docker
 
-As an alternative to a local installation, a prebuilt container image is published at ``ghcr.io/cameronabrams/htpolynet``.  It bundles htpolynet together with Gromacs, AmberTools, and OpenBabel, so no additional dependencies are required on the host beyond Docker (and, optionally, the NVIDIA Container Toolkit for GPU runs).
+As an alternative to a local installation, a prebuilt container image is published at ``ghcr.io/cameronabrams/htpolynet``.  It bundles htpolynet together with Gromacs, AmberTools, and OpenBabel, so no additional dependencies are required on the host beyond Docker.
 
 Run htpolynet against a configuration file in the current directory:
 ```bash
 docker run --rm -v $(pwd):/work ghcr.io/cameronabrams/htpolynet run config.yaml
 ```
 
-With GPU support:
-```bash
-docker run --rm --gpus all -v $(pwd):/work ghcr.io/cameronabrams/htpolynet run config.yaml
-```
+**The image cannot use a GPU.**  Its Gromacs comes from conda-forge, built against OpenCL rather than CUDA, and Gromacs no longer drives NVIDIA devices through OpenCL.  Passing `--gpus all` starts the container and changes nothing about how it computes; on a cluster, target CPU partitions and do not request `--gres=gpu` or pass `--nv`.  If you need GPU-accelerated Gromacs, install htpolynet natively against a CUDA-enabled Gromacs.
 
 A Docker Compose file is also provided in [docker/compose.yml](docker/compose.yml) for a shorter invocation (``docker compose run --rm htpolynet run config.yaml``).  See [docs/source/user-guide/container-usage.rst](docs/source/user-guide/container-usage.rst) for the full story, including Singularity/Apptainer use on HPC systems.
 

{htpolynet-2.3.1 → htpolynet-2.5.0}/README.md

@@ -33,21 +33,24 @@ pip install -e .
 
 Once installed, the user has access to the main ``htpolynet`` command.
 
+If you drive htpolynet with [Claude Code](https://claude.com/claude-code), install the bundled skill so the agent knows how to use it:
+```bash
+htpolynet setup-claude
+```
+This writes `~/.claude/skills/htpolynet/SKILL.md`; nothing is installed there unless you run it.
+
 IMPORTANT NOTES: The programs ``antechamber``, ``parmchk2`` and ``tleap`` from AmberTools must be in your path.  These can be installed using the ``ambertools`` package from ``conda-forge`` or compiled from source.  You also need Gromacs installed so ``gmx`` is in your path.  The examples show how to build input monomer structures using OpenBabel, so to use them you need ``obabel`` in your path as well.
 
 ## Docker
 
-As an alternative to a local installation, a prebuilt container image is published at ``ghcr.io/cameronabrams/htpolynet``.  It bundles htpolynet together with Gromacs, AmberTools, and OpenBabel, so no additional dependencies are required on the host beyond Docker (and, optionally, the NVIDIA Container Toolkit for GPU runs).
+As an alternative to a local installation, a prebuilt container image is published at ``ghcr.io/cameronabrams/htpolynet``.  It bundles htpolynet together with Gromacs, AmberTools, and OpenBabel, so no additional dependencies are required on the host beyond Docker.
 
 Run htpolynet against a configuration file in the current directory:
 ```bash
 docker run --rm -v $(pwd):/work ghcr.io/cameronabrams/htpolynet run config.yaml
 ```
 
-With GPU support:
-```bash
-docker run --rm --gpus all -v $(pwd):/work ghcr.io/cameronabrams/htpolynet run config.yaml
-```
+**The image cannot use a GPU.**  Its Gromacs comes from conda-forge, built against OpenCL rather than CUDA, and Gromacs no longer drives NVIDIA devices through OpenCL.  Passing `--gpus all` starts the container and changes nothing about how it computes; on a cluster, target CPU partitions and do not request `--gres=gpu` or pass `--nv`.  If you need GPU-accelerated Gromacs, install htpolynet natively against a CUDA-enabled Gromacs.
 
 A Docker Compose file is also provided in [docker/compose.yml](docker/compose.yml) for a shorter invocation (``docker compose run --rm htpolynet run config.yaml``).  See [docs/source/user-guide/container-usage.rst](docs/source/user-guide/container-usage.rst) for the full story, including Singularity/Apptainer use on HPC systems.
 

{htpolynet-2.3.1 → htpolynet-2.5.0}/ROADMAP.md

@@ -8,55 +8,57 @@ Rough ordering within each section is by value, not by effort.
 
 ## Container and deployment
 
-- **CUDA-enabled Gromacs in the container image.** The published image
-  installs Gromacs from conda-forge, whose default linux-64 package is
-  built with OpenCL (not CUDA) and generic `AVX2_256` SIMD. Gromacs no
-  longer drives NVIDIA devices through OpenCL, so the image cannot use a
-  GPU at all, and on an AVX-512 host it also leaves single-core
-  throughput on the table. For reference, Picotte's own module is
-  `AVX_512` + CUDA. Doing this well probably means a second image tag
-  (e.g. `:cuda`) built against `gromacs=*=nompi_cuda*` rather than
-  changing the default, since it pulls in the CUDA runtime and inflates
-  the image substantially, and it needs a GPU-equipped runner or a
-  manual build to verify. The CPU image should stay the default so that
-  `docker run` on a laptop keeps working. Note that
-  `software.gpu_unusable_reasons()` already reasons about this correctly,
-  so a CUDA image would simply start passing its checks rather than
-  needing new logic.
+- **The container's Gromacs is generic `AVX2_256`, on both tags.** The
+  `:cuda` image fixes the GPU half of this problem and not the SIMD half:
+  conda-forge builds for a portable baseline, so on an AVX-512 host both
+  images leave single-core throughput on the table relative to a natively
+  built or module-provided Gromacs. This is inherent to installing Gromacs
+  from conda-forge and cannot be fixed by choosing a different build string
+  -- it would take building Gromacs in the image, which trades the weekly
+  rebuild's freshness for a long build and a host-specific artifact.
+
+  Confirmed on hardware 2026-08-25: the `:cuda` image on Picotte's gpu001
+  reports `SIMD instructions: AVX2_256` on a node whose CPUs support
+  AVX-512, and Gromacs itself prints the hint that "AVX_512 ...
+  instructions will perform best on this hardware". Still unquantified, and
+  that is what would decide whether it matters: nobody has run the same
+  system against Picotte's own `abramsGrp-gromacs/2021.2/cpu-gpu` module on
+  the same node. Note Gromacs also observes that AVX2 is often the better
+  choice for runs that offload to a GPU anyway, so the penalty may be small
+  for exactly the case the `:cuda` image serves.
+
 - **Publish a digest or version tag people can pin.** `:latest` moves
   every week via the scheduled rebuild, so a run recorded as "built with
   the container" is not reproducible. Per-commit tags already exist;
   what's missing is documenting that users should pin one.
 
-- **The container cannot report which commit built it, and its version
-  string is actively misleading between releases.** `htpolynet info` used to
-  print `git commit: unknown` inside the image, because `_get_git_commit()`
-  runs `git rev-parse` against the installed package directory and no
-  installed copy has a `.git` beside it. That now falls back to the
-  installed distribution version, which is right for a pip or conda install
-  and *precisely wrong for the container*: the scheduled rebuild builds from
-  `main` HEAD, which can be many commits past the last tag, so the image
-  reports its `pyproject.toml` version honestly while running code that is
-  not that version.
-
-  This is live, not hypothetical. The 2026-08-24 03:54 scheduled build moved
-  `:latest` to an image built from `948c301` -- four commits past `v2.3.0`
-  -- and that image reports `installed version 2.3.0`. `:latest` is the
-  default thing a user pulls and the weekly cron is what keeps moving it, so
-  the wrong answer is the common case, and it is wrong silently. A user
-  could pull `:latest`, trust the version string, and write "htpolynet
-  2.3.0" in a methods section while having run untagged `main`.
-
-  The fix is to bake the real commit in at image build time -- the build
-  context has `.git`, so `docker.yml` or the Dockerfile can capture
-  `git rev-parse HEAD` and write it where the package can read it. That
-  touches the Dockerfile and the release story together, which is why it was
-  kept out of the bugfix that added the version fallback. It belongs with
-  the build-manifest entry below: both answer "what produced this build",
-  and a manifest that recorded an unreliable version string would launder
-  the problem rather than solve it. Raised by the calibration study, which
-  has correct provenance only because it pins the image by full sha
-  externally -- which remains the right practice either way.
+- **The image's Gromacs and AmberTools are unpinned, so two images with
+  identical htpolynet code can compute different numbers.** `docker/Dockerfile`
+  installs `ambertools`, `gromacs`, `parmed` and `rdkit` from conda-forge with
+  no version constraints, and the weekly rebuild exists precisely to pick up
+  whatever is newest. So the commit stamp now tells you which htpolynet
+  produced a build, and still does not tell you which force-field tool chain
+  did. Observed live: the image built 2026-08-25 carries AmberTools 26.0 and
+  Gromacs 2026.3, while panacea's native environment is on Gromacs
+  2025.4 -- a different major version against the same htpolynet.
+
+  Unpinning is deliberate and mostly right: pinning would freeze the image on
+  old Gromacs and defeat the point of a weekly rebuild. The gap is that
+  nothing *records* what a given image resolved to, so the versions are
+  discoverable only by running `htpolynet info` inside it and writing the
+  answer down by hand. The better of two candidates is an image
+  **label** carrying a `conda list` export, written at build time: `docker
+  inspect` then answers the question without running the image, so the record
+  survives reaching someone who cannot run the container at all -- a reviewer,
+  an archive, a future reader holding only the digest. The alternative, making
+  `htpolynet info` machine-readable so a build can capture it, requires the
+  image to still be runnable, which is the weaker guarantee. This is the same
+  requirement as the build manifest below, one layer further down -- what
+  produced this build, all the way to the compilers.
+
+  Raised by the calibration study, which found the 2025.4/2026.3 split only
+  because it went looking after an unrelated prompt.
+
 - **Retire `ghcr.io/abramsgroup/htpolynet`.** Superseded by the
   `cameronabrams` package; still public and still serving a June image to
   anyone with an old link.
@@ -93,6 +95,40 @@ Coverage as of the last measurement: **38.8%** overall.
 
 ## Release and distribution
 
+- **The release preflight cannot tell whether the *previous* release
+  actually shipped to conda-forge.** `scripts/check-conda-sync.py` compares
+  `pyproject.toml`'s runtime deps against the feedstock recipe, which
+  catches dependency drift the autotick bot cannot handle. It says nothing
+  about whether the bot's last PR ever merged. That gap ran for four
+  releases: `pip check` in the recipe's test section started failing when
+  `ambertools` began pulling in distributions with unsatisfiable metadata,
+  so the bot PRs for 2.2.0, 2.3.0, 2.3.1 and 2.4.0 all sat red and unmerged
+  while conda-forge served 2.1.0 from June. Every one of those releases
+  passed the preflight, because the deps genuinely did match. Nobody
+  noticed until a bot email got read.
+
+  Fixed on 2026-08-26 by dropping `pip check` from the recipe's test section
+  (it fails on `ambertools`' bundled distributions, never on ours) and
+  merging the 2.4.0 bump, which closed the other three. **The damage is
+  permanent and visible**: conda-forge's version list for this package now
+  reads 1.0.9 -> 2.1.0 -> 2.4.0, because 2.2.0, 2.3.0 and 2.3.1 were never
+  built there and never will be. That is worth knowing as a diagnostic in
+  its own right -- a published version list that skips releases the project
+  actually made is the retroactive signature of this failure, in any
+  package, without needing to have run any check at the time.
+
+  The check is cheap: query `api.anaconda.org/package/conda-forge/htpolynet`
+  for `latest_version` and compare it against the version being superseded.
+  A mismatch does not have to block the release -- the fix is usually on the
+  feedstock, not here -- but it must be loud, because the failure mode is
+  silence. Consider also listing open PRs on the feedstock, since a red bot
+  PR is the specific thing to look at.
+
+  The deeper point is that publishing to conda-forge is the one leg of the
+  release that completes *after* `release.sh` exits and on someone else's
+  infrastructure, so it is the only one that can fail without anything here
+  noticing.
+
 - **External services still keyed to the old repo identity.** The Aug 2026
   transfer from `AbramsGroup/HTPolyNet` to `cameronabrams/htpolynet` moved
   the code but left every integration pointing at the old owner. Three
@@ -107,6 +143,12 @@ Coverage as of the last measurement: **38.8%** overall.
   query". Fix the RTD project URL, then activate the tagged version. Worth
   keeping this list as the checklist if the repo ever moves again.
 
+  A fourth instance turned up on 2026-08-26 and is fixed: the conda-forge
+  recipe's `about:` block still gave `AbramsGroup/HTPolyNet` for `home` and
+  `dev_url`, and a `doc_url` of `abramsgroup.github.io/HTPolyNet` that
+  returns 404. Corrected in the same feedstock PR that unblocked the version
+  bumps.
+
 
 - **Mint a software DOI.** Enable the Zenodo GitHub integration for
   `cameronabrams/htpolynet`, then the next `scripts/release.sh` run
@@ -122,6 +164,55 @@ Coverage as of the last measurement: **38.8%** overall.
   it read `3.10 | 3.11 | 3.12 | 3.13`, which CI already verifies at both
   ends.
 
+## Cure and repair
+
+- **`completion_bias` biases the `B` side only, and that is a convention,
+  not a law.** The new `CURE.controls.completion_bias` ranks bond candidates
+  by how many bonds their `B`-side residue already carries, because
+  htpolynet's A2+B3 idiom puts the multifunctional crosslinker in the `B`
+  position -- as example 6 does. A user who declares the crosslinker as `A`
+  gets no bias at all, silently, because every candidate scores zero on a
+  difunctional bridge and the ordering collapses back to distance. The
+  generalization is small (rank on the `A` side, or on the sum of both) but
+  each variant is a different physical claim about which partly-reacted
+  species is an intermediate, and none of them has been run. Do it when
+  someone has a chemistry that needs it, and make them say which side.
+
+- **Nobody has run example 6 with `completion_bias` on.** The ranking is
+  unit-tested -- ordering, tie-breaks, missing residues, the fallback when a
+  `.grx` predates the `nreactions` attribute -- but the acceptance criteria
+  that matter are system-scale and need gmx and a multi-hour build:
+  incomplete triazines should collapse from tens to ~1 at
+  `desired_conversion: 0.90`, crosslinker conversion should rise from ~0.76
+  to ~0.90, `TAZ + CYN/3` must still equal the initial triazine count
+  exactly, and atom conservation must still be exact. If the incomplete
+  count does *not* collapse, the sort key is not surviving as far as the
+  truncation and that is where to look. Until someone runs it, the directive
+  is documented as untested at scale.
+
+- **The repair stage's cap placement does not scale to low conversion.**
+  At a bond conversion of 0.90 the triazine-to-cyanate driver places on the
+  order of a hundred caps; at 0.30 it places hundreds and transfers hundreds
+  of fragments, and runs have died at the repair NVT with a step-0 potential
+  energy around 7e15 dominated by Lennard-Jones -- atom overlap from cap
+  placement. It is packing-dependent rather than systematic: siblings at the
+  same conversion survive. `completion_bias` makes the stage nearly empty
+  and so hides this, but the geometry is still wrong for a crowded box, and
+  a sub-gel-point study that wants the unbiased ranking will hit it again.
+  The fix is in `repair/cyanate_cap.py::_place_cyn_along` and the greedy
+  matcher around it: place against the local neighbourhood rather than along
+  the old O-H vector alone, or minimize incrementally as caps are placed.
+
+- **`bdf.loc[:abs_max]` takes one bond more than the limit.** In
+  `curecontroller.py::_searchbonds`, the truncation that applies
+  `max_conversion_per_iteration` uses `.loc` with a slice, which is
+  inclusive of its endpoint, so an iteration limited to `n` bonds forms
+  `n + 1`. Harmless in practice -- the limit is a throttle, not a
+  correctness bound -- but it is off by one, and fixing it changes the
+  trajectory of every existing config by one bond per throttled iteration.
+  Worth doing at a version boundary where a small reproducibility break is
+  already expected, not before.
+
 ## Usability
 
 - **`gen-slurm-script` doesn't stage to scratch.** The emitted script
@@ -152,33 +243,6 @@ Coverage as of the last measurement: **38.8%** overall.
   cyanate-ester bridge series meant doing (a) and (b) by hand in a throwaway
   RDKit script, which is exactly the work a user should not have to
   reinvent.
-- **The bundled Claude skill only reaches people working in a clone.**
-  `.claude/skills/htpolynet/` is picked up when the working directory is the
-  repository, which covers contributors and anyone who cloned to run the
-  examples -- but not the ordinary user who `pip install`s or
-  `conda install`s htpolynet and works in their own project directory, which
-  is most of them. Whether to ship it inside the package is undecided.
-
-  Two things to settle before doing so, neither obvious:
-
-  1. **The skill would be broken as written.** Its central move is "read
-     `docs/source/user-guide/building-a-system.rst`", a repo path that does
-     not exist for an installed user. A shipped version would have to point
-     at the Read the Docs URL instead, or the guide would have to ship as
-     package data. The first is simpler and goes stale differently -- an RTD
-     link tracks `latest`, so an installed 2.3.0 would send its reader to
-     documentation for whatever is current.
-  2. **Delivery.** A skill file inside a wheel does nothing on its own;
-     something has to place it where the tool looks. An `htpolynet skill
-     --install` subcommand copying it into the user's `~/.claude/skills/`
-     is the obvious mechanism, and is also the point at which a scientific
-     package starts carrying vendor-specific tooling and an install-time
-     side effect on a directory it does not own.
-
-  Worth weighing against simply doing nothing: the procedural guide the skill
-  points at is on Read the Docs already, and an agent that reads
-  documentation gets the same content without any of this.
-
 - **Generated topologies cannot be compared byte-wise, because ParmEd
   stamps them.** Every `.top` htpolynet writes opens with a ParmEd header
   recording the invoking user, the host, and the date:
@@ -326,10 +390,37 @@ Coverage as of the last measurement: **38.8%** overall.
   example anneals at a 500 K peak, and the measured *T*:sub:`g` for this
   system is 487.9 K. That is 12.1 K above the glass transition, for 80 ps.
   The Tg ladder that produced the relaxed value spent 15,785 ps above
-  *T*:sub:`g`, peaking 112 K above it -- 197x the time, in the only regime
-  where a crosslinked network moves at all. Lengthening an anneal that sits
-  12 K above *T*:sub:`g` extends a process that barely moves anything, so
-  the lever is the peak temperature, not the duration.
+  *T*:sub:`g`, peaking 112 K above it -- 197x the time, in the regime where
+  a crosslinked network actually moves. Lengthening an anneal that sits 12 K
+  above *T*:sub:`g` extends a process that barely moves anything, so the
+  lever is the peak temperature, not the duration.
+
+  **But raising the peak is unlikely to close the gap entirely.** Two
+  structures of the same network were held for 5 ns at a 480 K setpoint
+  that thermostatted to 477.1 K -- about 11 K *below* the measured
+  *T*:sub:`g`, and far longer than the 80 ps the example spends near it.
+  Relaxation there is fast at first and then stops: about 87% of an
+  initial 34.8 kg/m³ density gap -- the gap measured over the first 200 ps
+  -- closes within 3 ns, and the remaining 4.25 kg/m³ persists at
+  7.2 sigma, with a last-half trend of +0.030 kg/m³/ns, i.e. not decaying.
+  (State the baseline and the window whenever this number is quoted: the
+  same data give 83.5-87.8% across the defensible choices of each, so a
+  bare percentage is not a fact.)  So heat and time buy most of the
+  relaxation quickly and then buy nothing, and a residual difference
+  survives that a longer anneal at this scale does not appear able to
+  remove.  Whatever replaces the current anneal should
+  therefore be argued as a large improvement, not as a fix; an entry
+  promising equilibration would oversell what was measured.
+
+  Note what that hold also says about *T*:sub:`g` itself: **relaxation does
+  not switch off at the glass transition**, it slows continuously through
+  it.  A transition 20-34 K wide by experiment means 11 K below
+  *T*:sub:`g` is inside the transition, not deep in the glass, so fast
+  early relaxation there is expected rather than anomalous.  This does not
+  soften the argument above -- the 197x figure is unchanged and a peak well
+  clear of the transition is still the lever -- but it does mean *T*:sub:`g`
+  is a soft kinetic boundary for this material, which any protocol
+  expressed relative to it has to accommodate.
 
   **Untested.** Nobody has yet built with a hotter anneal and compared it
   against the melt-and-recool value, which is the experiment that would