qprogram-qdac 0.1.0__tar.gz → 0.2.0__tar.gz

qprogram_qdac-0.2.0/CHANGELOG.md

@@ -0,0 +1,23 @@
+# Changelog
+
+Notable changes to QProgram QDAC, newest first. Each entry starts life as a news fragment under `changelog/`, and `towncrier build` assembles the fragments into a release section here. See [Contributing](https://qilimanjaro-tech.github.io/qprogram-qdac/developer/contributing.html) for how to add one.
+
+<!-- towncrier release notes start -->
+
+## 0.2.0 (2026-09-08)
+
+This release requires qprogram 0.2, which is what a `require qdac` line is now read against. One thing follows from the core release rather than from anything here: a `.qp` file written before it no longer loads, because its `#!QProgram 1.0` header reads as a later version than the `0.2` the core writes now, and nothing runs backwards. A file whose header is current is carried up instead, since a `require qdac` line naming an earlier major is migrated rather than refused.
+
+### Changed
+
+- The `require qdac <major>.<minor>` line is read by the rule the core DSL applies to a file header, which needs qprogram 0.2. A line asking for more than the installed package provides is still refused, and the message now names what to install: `file requires qdac 1.0, newer than the installed qdac 0.2.0 — install qdac 1.0 or newer`. A line carrying a patch (`require qdac 0.1.0`) is refused rather than rounded down, since a patch release of this package changes code and never the wire form. A line naming an earlier major loads instead of being refused, so a release that changes an operation's wire form registers a rewrite for it with `qp.register_vendor_migration("qdac", "<major>.<minor>")` and the files users already have go on loading. Nothing in this package's own API changes. ([PR #4](https://github.com/qilimanjaro-tech/qprogram-qdac/pull/4))
+
+
+## 0.1.0 (2026-08-25)
+
+### Added
+
+- First release. QProgram QDAC adds the `qdac` vendor namespace to the core DSL, covering the QDevil QDAC, a slow high-precision DAC used most often for flux biasing. Importing the package is what turns it on.
+- Four operations covering DC offsets, the waveform engine, and the chassis trigger network.
+- A capability profile describing what a QDAC channel can do, so a program is validated against the hardware before it is run.
+- `.qp` serialization for everything the package adds, registered so that a file naming the `qdac` vendor resolves without the caller importing this package first.

{qprogram_qdac-0.1.0 → qprogram_qdac-0.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: qprogram-qdac
-Version: 0.1.0
+Version: 0.2.0
 Summary: QDevil QDAC vendor extensions for the QProgram pulse-level quantum programming DSL.
 Project-URL: Homepage, https://github.com/qilimanjaro-tech/qprogram-qdac
 Project-URL: Documentation, https://qilimanjaro-tech.github.io/qprogram-qdac/
@@ -27,26 +27,16 @@ Classifier: Topic :: Scientific/Engineering :: Physics
 Classifier: Topic :: Scientific/Engineering :: Quantum Computing
 Classifier: Typing :: Typed
 Requires-Python: >=3.11
-Requires-Dist: qprogram>=0.1.0
+Requires-Dist: qprogram>=0.2.0
 Description-Content-Type: text/markdown
 
 # QProgram QDAC
 
-[![Tests](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/tests.yml/badge.svg)](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/tests.yml)
-[![Code Quality](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/code_quality.yml/badge.svg)](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/code_quality.yml)
-[![Python](https://img.shields.io/badge/python-3.11%20%7C%203.12%20%7C%203.13%20%7C%203.14-blue)](https://www.python.org/)
-[![License](https://img.shields.io/badge/license-Apache%202.0-blue)](LICENSE)
+[![Tests](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/tests.yml/badge.svg)](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/tests.yml) [![Code Quality](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/code_quality.yml/badge.svg)](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/code_quality.yml) [![Python](https://img.shields.io/badge/python-3.11%20%7C%203.12%20%7C%203.13%20%7C%203.14-blue)](https://www.python.org/) [![License](https://img.shields.io/badge/license-Apache%202.0-blue)](LICENSE)
 
-QDevil QDAC extensions for
-[QProgram](https://github.com/qilimanjaro-tech/qprogram), the pulse-level
-quantum programming DSL. The QDAC is a slow high-precision DAC, used most
-often for flux biasing.
+QDevil QDAC extensions for [QProgram](https://github.com/qilimanjaro-tech/qprogram), the pulse-level quantum programming DSL. The QDAC is a slow high-precision DAC, used most often for flux biasing.
 
-The core DSL knows nothing about any instrument. This package adds the
-`qdac` vendor namespace to it: four operations covering DC offsets, the
-waveform engine, and the chassis trigger network, a capability profile that
-says what a QDAC channel can do, and `.qp` serialization for all of it.
-Importing the package is what turns those on.
+The core DSL knows nothing about any instrument. This package adds the `qdac` vendor namespace to it: four operations covering DC offsets, the waveform engine, and the chassis trigger network, a capability profile that says what a QDAC channel can do, and `.qp` serialization for all of it. Importing the package is what turns those on.
 
 ## Installation
 
@@ -90,43 +80,19 @@ data = result.get(m0)
 print(data.dims, data.shape)  # ('bias', 'IQ') (41, 2)
 ```
 
-The flux bias comes from the QDAC, the drive and readout from whatever
-vendor owns those buses. One program describes both, and the nesting is
-what makes a mixed platform accept it: the bias sweep dispatches from the
-host, one upload per point, while the `average` block under it runs in the
-real-time sequencer. Flatten the two into one block and no domain runs
-both. `sync` names its buses because the argument-less form syncs every bus
-in the program, and a QDAC channel is not something a real-time barrier can
-wait on.
+The flux bias comes from the QDAC, the drive and readout from whatever vendor owns those buses. One program describes both, and the nesting is what makes a mixed platform accept it: the bias sweep dispatches from the host, one upload per point, while the `average` block under it runs in the real-time sequencer. Flatten the two into one block and no domain runs both. `sync` names its buses because the argument-less form syncs every bus in the program, and a QDAC channel is not something a real-time barrier can wait on.
 
 ## What you get
 
-- **Four operations under one namespace.** `set_offset` holds a DC voltage
-  on a channel, `play` uploads an envelope to the channel's waveform engine
-  with explicit dwell, delay, repetitions and stepped mode, and
-  `set_trigger` / `wait_trigger` wire the channel into the chassis trigger
-  network so QDAC sequences line up with instruments driving other buses.
-- **Host-side sweeps, declared rather than guessed.** The QDAC has no FPGA,
-  so a swept parameter has to be re-uploaded from the host between
-  iterations. The `qdac-default-v1` profile says so through a domain
-  constraint, and `qp.explain(program, capabilities)` prints the enclosing
-  loop as `[host]` instead of failing at compile time.
-- **Single-channel by declaration.** The profile lists only single-channel
-  waveform tokens. An IQ waveform on a QDAC bus is a `missing-capability`
-  error from `qp.validate`, not a runtime surprise.
-- **Serialization included.** Every operation round-trips through the `.qp`
-  text format, under a `require qdac 0.1` header line. A file that names
-  `qdac` activates this package on load through its entry point, so the
-  reader does not have to import it first.
-- **Typed access.** `QProgram` from this package is the core builder with a
-  typed `.qdac` property. `QdacMixin` composes with other vendor mixins
-  when a platform spans several instruments.
+- **Four operations under one namespace.** `set_offset` holds a DC voltage on a channel, `play` uploads an envelope to the channel's waveform engine with explicit dwell, delay, repetitions and stepped mode, and `set_trigger` / `wait_trigger` wire the channel into the chassis trigger network so QDAC sequences line up with instruments driving other buses.
+- **Host-side sweeps, declared rather than guessed.** The QDAC has no FPGA, so a swept parameter has to be re-uploaded from the host between iterations. The `qdac-default-v1` profile says so through a domain constraint, and `qp.explain(program, capabilities)` prints the enclosing loop as `[host]` instead of failing at compile time.
+- **Single-channel by declaration.** The profile lists only single-channel waveform tokens. An IQ waveform on a QDAC bus is a `missing-capability` error from `qp.validate`, not a runtime surprise.
+- **Serialization included.** Every operation round-trips through the `.qp` text format, under a `require qdac 0.2` header line. A file that names `qdac` activates this package on load through its entry point, so the reader does not have to import it first.
+- **Typed access.** `QProgram` from this package is the core builder with a typed `.qdac` property. `QdacMixin` composes with other vendor mixins when a platform spans several instruments.
 
 ## Documentation
 
-Full documentation, including the operation reference, the capability
-profile, and the generated API reference, lives at
-<https://qilimanjaro-tech.github.io/qprogram-qdac/>.
+Full documentation, including the operation reference, the capability profile, and the generated API reference, lives at <https://qilimanjaro-tech.github.io/qprogram-qdac/>.
 
 ## Development
 

qprogram_qdac-0.2.0/README.md

@@ -0,0 +1,83 @@
+# QProgram QDAC
+
+[![Tests](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/tests.yml/badge.svg)](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/tests.yml) [![Code Quality](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/code_quality.yml/badge.svg)](https://github.com/qilimanjaro-tech/qprogram-qdac/actions/workflows/code_quality.yml) [![Python](https://img.shields.io/badge/python-3.11%20%7C%203.12%20%7C%203.13%20%7C%203.14-blue)](https://www.python.org/) [![License](https://img.shields.io/badge/license-Apache%202.0-blue)](LICENSE)
+
+QDevil QDAC extensions for [QProgram](https://github.com/qilimanjaro-tech/qprogram), the pulse-level quantum programming DSL. The QDAC is a slow high-precision DAC, used most often for flux biasing.
+
+The core DSL knows nothing about any instrument. This package adds the `qdac` vendor namespace to it: four operations covering DC offsets, the waveform engine, and the chassis trigger network, a capability profile that says what a QDAC channel can do, and `.qp` serialization for all of it. Importing the package is what turns those on.
+
+## Installation
+
+```bash
+pip install qprogram-qdac
+```
+
+The only dependency is `qprogram` itself.
+
+## A first program
+
+```python
+import qprogram as qp
+from qprogram import BusSchema
+from qprogram.waveforms import IQPair, Square
+from qprogram_qdac import QProgram
+
+schema = BusSchema.flux_tunable_transmon()
+q = schema.q
+
+program = QProgram(label="flux-spectroscopy", schema=schema)
+bias = program.variable("bias", units="V")
+
+with program.sweep(bias).from_range(-0.2, 0.2, 0.01):
+    program.qdac.set_offset(q[0].flux, bias)
+    with program.average(shots=100):
+        program.play(q[0].drive, "pi_pulse")
+        program.sync([q[0].drive, q[0].readout])
+        m0 = program.measure(q[0].readout, "readout", "weights")
+
+resolved = program.with_waveforms(
+    {
+        "pi_pulse": IQPair(Square(0.5, 40), Square(0.0, 40)),
+        "readout": IQPair(Square(1.0, 2000), Square(0.0, 2000)),
+        "weights": IQPair(Square(1.0, 2000), Square(1.0, 2000)),
+    }
+)
+
+result = qp.simulate(resolved)
+data = result.get(m0)
+print(data.dims, data.shape)  # ('bias', 'IQ') (41, 2)
+```
+
+The flux bias comes from the QDAC, the drive and readout from whatever vendor owns those buses. One program describes both, and the nesting is what makes a mixed platform accept it: the bias sweep dispatches from the host, one upload per point, while the `average` block under it runs in the real-time sequencer. Flatten the two into one block and no domain runs both. `sync` names its buses because the argument-less form syncs every bus in the program, and a QDAC channel is not something a real-time barrier can wait on.
+
+## What you get
+
+- **Four operations under one namespace.** `set_offset` holds a DC voltage on a channel, `play` uploads an envelope to the channel's waveform engine with explicit dwell, delay, repetitions and stepped mode, and `set_trigger` / `wait_trigger` wire the channel into the chassis trigger network so QDAC sequences line up with instruments driving other buses.
+- **Host-side sweeps, declared rather than guessed.** The QDAC has no FPGA, so a swept parameter has to be re-uploaded from the host between iterations. The `qdac-default-v1` profile says so through a domain constraint, and `qp.explain(program, capabilities)` prints the enclosing loop as `[host]` instead of failing at compile time.
+- **Single-channel by declaration.** The profile lists only single-channel waveform tokens. An IQ waveform on a QDAC bus is a `missing-capability` error from `qp.validate`, not a runtime surprise.
+- **Serialization included.** Every operation round-trips through the `.qp` text format, under a `require qdac 0.2` header line. A file that names `qdac` activates this package on load through its entry point, so the reader does not have to import it first.
+- **Typed access.** `QProgram` from this package is the core builder with a typed `.qdac` property. `QdacMixin` composes with other vendor mixins when a platform spans several instruments.
+
+## Documentation
+
+Full documentation, including the operation reference, the capability profile, and the generated API reference, lives at <https://qilimanjaro-tech.github.io/qprogram-qdac/>.
+
+## Development
+
+The project uses [uv](https://docs.astral.sh/uv/).
+
+```bash
+git clone https://github.com/qilimanjaro-tech/qprogram-qdac
+cd qprogram-qdac
+
+uv sync --group dev                  # create .venv and install everything
+uv run pytest                        # run the test suite
+uv run ruff check .                  # lint
+uv run ruff format .                 # format
+uv run ty check                      # type-check
+uv run --group docs zensical serve   # preview the documentation
+```
+
+## License
+
+Apache License 2.0 - see [LICENSE](LICENSE).

qprogram_qdac-0.2.0/docs/developer/contributing.md

@@ -0,0 +1,148 @@
+# Contributing
+
+The short version: open a small pull request, run the linter and the tests, write the docs for anything that changes user-visible behavior.
+
+## Before you start
+
+Skim two things first.
+
+1. **[Lowering onto hardware](lowering.md).** It explains the five modules, the registration hooks, and what a platform does with each operation. Almost every change touches one of those.
+2. **The core DSL's developer guide**, in particular [building a vendor extension](https://qilimanjaro-tech.github.io/qprogram/developer/vendor-extensions.html), the template this package follows, and [capability protocol internals](https://qilimanjaro-tech.github.io/qprogram/developer/capability-protocol.html), the normative account of tokens, slots and predicates. The AST, the validator, and the `.qp` format live there too. A change to this package that needs a core change is usually a core issue instead.
+
+Then decide which repository the change belongs in. An operation only a QDAC can do belongs here. Anything a second backend would also want belongs in the core, so every backend gets it.
+
+
+## Development workflow
+
+1. **Install the package.**
+
+   ```bash
+   uv sync --group dev
+   ```
+
+2. **Install the docs environment** (optional, only if you change docs).
+
+   ```bash
+   uv sync --group docs
+   uv run --group docs zensical serve
+   ```
+
+   `mkdocstrings` imports the package to render the API reference, so the docs build needs the project installed, not just the docs tooling.
+
+3. **Make your change.**
+
+4. **Lint and format.**
+
+   ```bash
+   uv run ruff check .
+   uv run ruff format .
+   ```
+
+5. **Type-check.**
+
+   ```bash
+   uv run ty check
+   ```
+
+6. **Run the tests.**
+
+   ```bash
+   uv run pytest
+   uv run pytest --cov=qprogram_qdac    # check coverage on touched files
+   ```
+
+7. **Update the docs.** Anything user-visible needs an entry in the relevant guide page and, for a new class or method, an entry in [`docs/reference/api.md`](../reference/api.md), whose `members:` lists are explicit.
+
+8. **Add a changelog entry.** Anything a caller would notice gets one news fragment under `changelog/`, named `<pr-number>.<type>.md`, where the type is `added`, `changed`, `fixed`, or `removed`.
+
+   ```bash
+   uv run towncrier create 123.added.md
+   ```
+
+   Write one or two sentences about what changed for somebody using the package. A fragment written before the pull request has a number takes a `+` prefix and any name, as in `+trigger-network-reset.added.md`; rename it once the number exists so the entry carries a link. Internal refactors, test-only changes, and docs corrections do not need one.
+
+9. **Open the pull request.** The workflows under `.github/workflows/` run on it. `tests.yml` runs the suite on Python 3.11 and 3.14 for a pull request, across 3.11 through 3.14 on a push to `main`, and uploads coverage from the 3.13 job. `code_quality.yml` runs `ruff check` and `ruff format --diff` once on 3.13, then `ty check` once per supported version. `docs.yml` builds this site, and deploys it on a push to `main`.
+
+## What "small PR" means
+
+One concept per pull request. A new operation plus a new predicate plus a serialization fix is three pull requests. Each one is easier to review, easier to revert, and easier to bisect against.
+
+## The checklist for a new operation
+
+All five code edits are listed in [Adding an operation](lowering.md#adding-an-operation). A complete pull request carries four kinds of change:
+
+| Kind              | What it means                                                                                                                    |
+|-------------------|----------------------------------------------------------------------------------------------------------------------------------|
+| **Code**          | The node in `operations.py`, the method on `QdacNamespace`, the token in `profiles.py` twice, the registration in `__init__.py`.   |
+| **Tests**         | One test per module in `tests/`: operations, namespace, serialization, registration, profile.                                      |
+| **Docs**          | The operation's row and section in the user guide, its wire form in the serialization page, and anything the platform must know in [Lowering onto hardware](lowering.md). |
+| **API reference** | The class and the namespace method added to the `members:` lists in `docs/reference/api.md`.                                       |
+
+Adding an operation is a minor version bump of the package, which is also the vendor protocol version in the `require qdac <major>.<minor>` header. Removing or renaming one, or changing what it means on the wire, is a major bump — and it needs a [migration](lowering.md#changing-one-that-already-exists) registered with `qp.register_vendor_migration("qdac", ...)` under the version that ships it, so the files users already have keep loading.
+
+## Style notes
+
+These are the rules the project enforces; they are not exhaustive. All of them are configured in `pyproject.toml`.
+
+- **Ruff with `preview = true` and `select = ["ALL"]`**, minus a curated ignore list written as rule *names* rather than codes, so the reason for each exemption reads off the config. Suppression comments use the same form: `# ruff: ignore[import-outside-top-level]`, never a numeric code. Line length is 120 and the formatter owns it. Expect the linter to push back on most external code.
+- **Docstrings are enforced.** Preview mode means both the `D` and the `DOC` families run, under the Google convention. Every parameter gets a `name (type): Description.` entry, with the parenthesized type as house style even though the signature is annotated. A non-`None` return needs a `Returns:` section unless the summary line already opens with the word "Return", and every exception a caller can observe needs a `Raises:` entry. Constructor arguments are documented on the **class** docstring, since `merge_init_into_class` is on and `undocumented-public-init` is ignored. `Attributes:` is for a value object whose fields are the interface and are not all constructor arguments.
+- **Cross-references are Markdown, not Sphinx roles.** Write `` [`SetOffset`][qprogram_qdac.SetOffset] `` for a target this site documents, and `` [`Expression`][qprogram.Expression] `` for one the core DSL documents: `zensical.toml` loads that project's published `objects.inv` as an `inventories` entry, so a core type resolves to its page on that site. Plain `` `Expression` `` is for anything neither site renders, such as a builtin or a stdlib name. A Sphinx role such as `` :class:`~qprogram.Expression` `` would reach the page as literal text, since mkdocstrings reads a docstring as Markdown and has no reStructuredText reader; `tests/test_docstring_style.py` fails the suite on one. The docs build runs with `--strict`, so a cross-reference neither site can resolve fails CI as well.
+- **Every file carries the Apache header**, the standard 13-line notice with `Copyright 2026 Qilimanjaro Quantum Tech`, above the module docstring. Ruff's `missing-copyright-notice` rule fails the lint on a file without it. Tests included.
+- **Type hints everywhere.** `ty` is in the dev group and checks `src`, and CI runs it once per supported Python version.
+- **Function-style tests.** No test classes. Use fixtures from `tests/conftest.py` and parametrization. Tests are exempt from the `ANN`, `D`, and `DOC` families, so a test needs no docstring, but one explaining *why* a case exists is worth writing.
+- **Two-space indentation in `.qp` fixtures.** That is what the writer emits.
+- **No new runtime dependencies.** This package depends on `qprogram` and nothing else, and that is on purpose. A vendor SDK belongs in the platform library that drives the instrument, not in the package that describes it.
+
+## What goes where
+
+| Change kind                        | Where it lands                                                        |
+|------------------------------------|-----------------------------------------------------------------------|
+| New operation                       | `src/qprogram_qdac/operations.py` plus the four other edits.          |
+| New method on the namespace         | `src/qprogram_qdac/namespace.py`.                                    |
+| New capability token or predicate   | `src/qprogram_qdac/profiles.py`.                                     |
+| New limit                           | `src/qprogram_qdac/profiles.py`, in `QDAC_DEFAULT_V1.limits`.         |
+| New profile bundle                  | `src/qprogram_qdac/profiles.py`, registered from `__init__.py`.       |
+| Registration or the typed program   | `src/qprogram_qdac/__init__.py`.                                     |
+| Docs                                | `docs/`; the nav lives in `zensical.toml`.                            |
+| Anything about the AST or `.qp`     | The core DSL, not here.                                               |
+
+## Releasing
+
+`CHANGELOG.md` is assembled from the fragments in `changelog/`, so it is written once per release rather than edited per PR. A release goes out from its own pull request:
+
+1. Branch from an up-to-date `main`.
+2. Set the new version. This writes both `pyproject.toml` and `uv.lock`; nothing else holds the literal, since the version is read from the installed metadata.
+
+   ```bash
+   uv version 0.2.0
+   uv sync
+   ```
+
+3. Assemble the changelog. Pass the version explicitly. Left to guess, towncrier reads the *installed* metadata and can render a stale number into a heading that is never regenerated.
+
+   ```bash
+   uv run towncrier build --draft --version "$(uv version --short)"   # preview
+   uv run towncrier build --version "$(uv version --short)" --yes
+   ```
+
+4. Read the rendered section and edit it. Fragments are written weeks apart by different people and rarely read as one voice when they land together.
+5. Open the release PR, and merge it once CI is green.
+6. Create the GitHub Release on the merge commit, tagged with the version now in `pyproject.toml` and no `v` prefix. Publishing it starts `publish.yml`, which runs `uv build` for the wheel and the sdist, checks both with `twine check`, and uploads them through trusted publishing. Pre-releases publish too.
+7. Approve the deployment. The run waits on the `pypi` environment until a reviewer releases it. PyPI never lets a file be replaced, so this approval is the last point at which a wrong version can be stopped.
+
+`publish.yml` can also be started by hand from the Actions tab, which is how the first release goes out and how a run that failed on a transient error is retried. A manual run takes three inputs: `platform` chooses between PyPI and the `qilimanjaro` AWS CodeArtifact domain, `repository` names the CodeArtifact repository, and `dry_run` builds and validates the distributions without uploading them.
+
+## Commit messages
+
+Short, imperative, explanatory. The body matters more than the title: explain *why*, not *what*. The history in `git log` is a good template.
+
+## License and attribution
+
+`qprogram-qdac` is licensed under the Apache License, Version 2.0. The full text is in the `LICENSE` file at the repository root, and every source file carries the matching 13-line header. By opening a pull request you agree to license your contribution under the same terms.
+
+## Where to ask
+
+- **Bug reports and feature requests.** Open a GitHub issue; the templates are short on purpose. Include a minimal program and, for anything about the file format, its `.qp` text. A problem that reproduces without importing `qprogram_qdac` belongs in the core repository.
+- **Design discussion.** Open an issue naming the affected code, the behavior you expect, and the guide page that documents it.
+
+Pull requests with a clear scope and tests are the fastest path to a merge.

{qprogram_qdac-0.1.0 → qprogram_qdac-0.2.0}/docs/developer/index.md

@@ -1,21 +1,12 @@
 # Developer guide
 
-These pages document the internals: what you need to drive real hardware from
-a QDAC program, and what you need to change this package.
+These pages document the internals: what you need to drive real hardware from a QDAC program, and what you need to change this package.
 
 | Topic                                 | What you find there                                                                                            |
 |---------------------------------------|----------------------------------------------------------------------------------------------------------------|
 | [Lowering onto hardware](lowering.md) | The module layout, the registration hooks, what a platform does with each operation, and how to add a new one. |
 | [Contributing](contributing.md)       | The uv workflow, the lint and test gate, style rules, and the checklist for a change.                          |
 
-The [User guide](../guide/index.md) covers the same operations from the caller's
-side, and the [API reference](../reference/api.md) is generated from the
-docstrings under `src/`, so the code and the reference move together.
+The [User guide](../guide/index.md) covers the same operations from the caller's side, and the [API reference](../reference/api.md) is generated from the docstrings under `src/`, so the code and the reference move together.
 
-This package is only the QDAC half. The AST, the `.qp` format, the capability
-protocol, and the reference executor all live in the core DSL. Two of its
-developer pages are the background for everything here:
-[building a vendor extension](https://qilimanjaro-tech.github.io/qprogram/developer/vendor-extensions.html)
-is the template this package follows, and
-[capability protocol internals](https://qilimanjaro-tech.github.io/qprogram/developer/capability-protocol.html)
-is the normative account of tokens, slots and predicates.
+This package is only the QDAC half. The AST, the `.qp` format, the capability protocol, and the reference executor all live in the core DSL. Two of its developer pages are the background for everything here: [building a vendor extension](https://qilimanjaro-tech.github.io/qprogram/developer/vendor-extensions.html) is the template this package follows, and [capability protocol internals](https://qilimanjaro-tech.github.io/qprogram/developer/capability-protocol.html) is the normative account of tokens, slots and predicates.