Adopt solprop's standard for issues and pull requests

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,12 @@
+# SPDX-FileCopyrightText: 2026 John C. Travers and contributors
+#
+# SPDX-License-Identifier: MIT
+
+blank_issues_enabled: true
+contact_links:
+  - name: How to write an issue
+    url: https://github.com/LupoLab/optmat/blob/main/CONTRIBUTING.md#writing-an-issue
+    about: What to check first, the sections and the labels.
+  - name: A problem with a propagation run
+    url: https://github.com/LupoLab/solprop/issues
+    about: The right values giving a wrong propagation belong with solprop.

.github/ISSUE_TEMPLATE/oep_tracking.md

@@ -0,0 +1,37 @@
+---
+name: OEP tracking issue
+about: For an OEP's author. One per OEP, except a Process OEP (OEP 0).
+title: "OEP N: "
+labels: oep, enhancement
+---
+
+<!--
+Add a priority, and an area where one fits. Name this issue in the OEP's Part III.
+Issues are public: no local paths, private notes or nicknames for machines.
+Delete these comments.
+-->
+
+Tracks [OEP N: Title](link to the OEP on `main`).
+
+<!-- What it proposes, in a sentence or two. -->
+
+### Where it stands
+
+- **Status:** … **Review:** … **Implementation:** …
+- **Requires:** …
+
+### What comes next
+
+- [ ] …
+
+### To resolve first
+
+<!-- What must be settled before it can go ahead. Leave this out if nothing must. -->
+
+### Related
+
+<!-- The open issues it will fix or change, as in its Context section, related OEPs and pull requests, and the solprop SEPs or issues that wait for it. -->
+
+### Done when
+
+The OEP reaches `Final`, `Rejected`, `Withdrawn` or `Superseded`, and this issue closes with it. A `Deferred` OEP keeps it open.

.github/ISSUE_TEMPLATE/offer_a_source.yml

@@ -0,0 +1,31 @@
+# SPDX-FileCopyrightText: 2026 John C. Travers and contributors
+#
+# SPDX-License-Identifier: MIT
+
+name: Offer a paper or data
+description: A measurement or calculation that optmat lacks, or better data than it holds.
+labels: [data]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Please search the [issues](https://github.com/LupoLab/optmat/issues?q=is%3Aissue) and the [curated sources](https://optmat.readthedocs.io/en/latest/the-data/sources.html) first. Cite the paper; do not attach its PDF or paste its tables, since the publishers' copyright applies.
+  - type: textarea
+    id: citation
+    attributes:
+      label: The source
+      description: The citation and DOI, or the data service or repository.
+    validations:
+      required: true
+  - type: textarea
+    id: content
+    attributes:
+      label: What it holds
+      description: The quantity, the materials, and the range of wavelength, temperature or density. Whether the values are printed in tables, in a supplement or only in figures, and the stated uncertainty if you know it.
+    validations:
+      required: true
+  - type: textarea
+    id: improves
+    attributes:
+      label: What it would improve
+      description: The model or the value it would change or check, and a page or register entry (`TC-n`) that bears on it, if you know one.

.github/ISSUE_TEMPLATE/planned_work.md

@@ -0,0 +1,49 @@
+---
+name: Planned work
+about: A bug, a data gap, a feature or a clean-up that someone can pick up from this text alone.
+---
+
+<!--
+The standard is in CONTRIBUTING.md, "Writing an issue". In short:
+
+- First search the issues, the pull requests, the OEPs and the register, and solprop's
+  issues if it consumes this, and link what you find.
+- Leave out any section that does not apply, and delete these comments.
+- Say what you ran and what you only read. Link code as a permalink to a commit.
+- Cite values to their source record and table or page, and to their register entry (TC-n).
+  Nothing from memory.
+- Mark a choice that is not the contributor's with **Needs a decision:**, saying who decides
+  and what you recommend.
+- Labels: one type, one priority, and an area where one fits.
+- Issues are public: no local paths, private notes or nicknames for machines, and no pasted
+  paper text or tables.
+-->
+
+### What happens
+
+<!-- Or what is missing, so that someone new to this code can follow it. -->
+
+### Why it matters
+
+<!-- What a user or a developer gets wrong or pays for today. -->
+
+### Reproduction
+
+<!--
+For a bug, the smallest script that shows it, which you have run, with its output.
+For a performance issue, the numbers, the machine, the build and the command.
+-->
+
+### Context
+
+<!-- Links to the code, the manual, OEPs, source records, register entries, pull requests and other issues, and the commit you checked against. -->
+
+### To do
+
+<!-- Actions, not restated symptoms. Name what must not change or break. -->
+
+- [ ] …
+
+### Done when
+
+<!-- What someone can check to know it is finished, with a tolerance and a machine for a measurement. -->

.github/ISSUE_TEMPLATE/report_a_value.yml

@@ -0,0 +1,41 @@
+# SPDX-FileCopyrightText: 2026 John C. Travers and contributors
+#
+# SPDX-License-Identifier: MIT
+
+name: Report a problem with a value
+description: A wrong value or model, a failure, or a suspected misprint in a paper. The maintainers fill in the rest.
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Please [search the issues](https://github.com/LupoLab/optmat/issues?q=is%3Aissue) first. The [review register](https://optmat.readthedocs.io/en/latest/register.html) may already record the disagreement or the doubt.
+  - type: textarea
+    id: value
+    attributes:
+      label: Which value or model
+      description: The material, the wavelength and conditions, and the function you called. A short script is ideal. For a misprint, the paper and where in it.
+      render: python
+    validations:
+      required: true
+  - type: textarea
+    id: expected
+    attributes:
+      label: What you expected
+      description: What you compared against (a paper with its table or page, an independent calculation, an instrument), and at what conditions. Cite a paper rather than pasting its tables.
+    validations:
+      required: true
+  - type: textarea
+    id: got
+    attributes:
+      label: What optmat gives
+      description: The value, or the output or the traceback.
+    validations:
+      required: true
+  - type: textarea
+    id: version
+    attributes:
+      label: Version
+      description: The output of `python -c "import optmat; print(optmat.__version__)"`.
+      render: text
+    validations:
+      required: true

AGENTS.md

@@ -9,7 +9,8 @@ The coding standards are conventional; **the data rules and the review register
 not negotiable.**
 
 **Read first:**
-- [`CONTRIBUTING.md`](CONTRIBUTING.md): the short guide.
+- [`CONTRIBUTING.md`](CONTRIBUTING.md): the short guide, and the standard for issues and
+  pull requests.
 - The manual pages *The curated data* (`docs/data.md`) and *The review register*
   (`docs/register.md`): the long form of the data format and of the register.
 - [OEP 0](docs/oeps/oep-0000-process.md), when the work is a major change: the
@@ -32,6 +33,8 @@ concerns physics or the reading of a paper rather than style, ask rather than gu
 | Data | `src/optmat/data/`: `sources/` (one record per paper), `values/<family>/<material>/` (extracted values), `external/` (third-party files), `materials.toml` (the material registry), `gas/` and `solid/` (model configurations and stored fits) |
 | Register | [`REGISTER.md`](REGISTER.md): the review register, cited as `TC-n` |
 | Enhancement proposals | `docs/oeps/`: OEPs for major changes; the process is OEP 0 (`oep-0000-process.md`), the form `template.md` |
+| Planned work | [GitHub issues](https://github.com/LupoLab/optmat/issues): open work goes in an issue, not on the roadmap, which lists only OEPs. [`CONTRIBUTING.md`](CONTRIBUTING.md) says how to write an issue and how to label an issue or a pull request |
+| Downstream | [solprop](https://github.com/LupoLab/solprop), the pulse-propagation code, depends on optmat from PyPI and builds on the interface of the manual page *Using optmat from a propagation code* ([its issues](https://github.com/LupoLab/solprop/issues), [its SEPs](https://solprop.readthedocs.io/en/latest/dev/seps/index.html)). optmat never depends on solprop |
 | Python | 3.12 or later (`requires-python`); development, the lock and the gate on 3.14 |
 | Licences | Code, source records and fits MIT; prose and figures CC-BY-4.0; published data (`data/values/`, `data/external/`) remain the publishers', shipped under the third-party data notice (`REUSE.toml`, `LICENSES/LicenseRef-optmat-third-party.txt`) |
 | CI | [`.github/workflows/ci.yml`](.github/workflows/ci.yml): the gate below on Linux and macOS, the tests on Windows, and the tests on Python 3.12 with the lowest supported dependencies |
@@ -129,15 +132,49 @@ Functionality built from an enhancement proposal is also not done until its phas
 is appended to the OEP (below). In your summary, say what you verified against a primary
 source and what you could not.
 
-**Proposal-only changes.** A change that only adds or edits OEPs, their index or their
-roadmap entries does not need the full gate. Run instead:
+**Documentation-only changes**, including adding or editing OEPs, their index or their
+roadmap entries, do not need the full gate. Run instead:
 - `git diff --check`;
 - `uv run codespell` on the changed files, and `uv run poe reuse` if files were added;
-- `uv run pytest tests/test_proposals.py tests/test_register.py`;
+- `uv run pytest tests/test_proposals.py tests/test_register.py`, and the tests that read
+  a page you changed (the `tests/test_*_page.py` of an accuracy page, the snippets' tests,
+  `tests/test_counts.py` for a front page);
 - `uv run poe docs`.
 
+The exception is based on content, not on a file's location. A change to code, tests,
+data, fixtures, a gallery script, dependencies, build configuration or tooling takes the
+full gate, and so does a mixed change. Report the checks actually run.
+
 ---
 
+## Working agreement
+
+- **Agree the plan for large changes.** A major change starts from an accepted OEP (below).
+  Any other change that touches more than a couple of files or alters a public signature
+  starts from an issue or a short agreed plan; a focused fix, a new source or a
+  documentation update does not need one.
+- **Stay in scope.** No refactoring, renaming or reformatting unrelated to the task.
+- **Open an issue for what you find.** Whatever you notice while working and do not fix
+  in the change in hand (a bug, a wrong statement, a missing test, a slow path) gets an
+  issue straight away, so that it outlives the work in hand and the branch. Do not wait to
+  be asked, and write it as [`CONTRIBUTING.md`](CONTRIBUTING.md) says, searching first. If
+  you plan to fix it yourself, open it all the same and keep it in your own plan too. A
+  doubt about data or a model also gets its `open` register entry.
+- **Connect a fix to its issue.** When you fix something you noticed, search the issues
+  for it, and solprop's if it consumes the result. If the change closes one of optmat's,
+  say `Closes #N` in the pull request; if it only goes part of the way or bears on one,
+  comment there on what changed and what is left, and do not close it. `Closes` acts only
+  on a pull request based on `main` in the same repository: after a stacked pull request
+  or a local merge reaches `main`, or for an issue in solprop, close or update it by hand,
+  naming the commit.
+- **Report failure honestly.** A check that fails, a test you could not make pass, an
+  assumption you had to invent: say it plainly. Silent partial completion is worse than an
+  admitted gap.
+- **The public tree stands alone.** No local paths, host names, private notes or links to
+  them, and no development identifiers, in code, tests, data, docs, the changelog, issues
+  or pull requests. Register numbers (`TC-n`) are public and are cited freely; the paper
+  library's contents are not, so cite a paper rather than pasting its text or tables.
+
 ## The review register
 
 [`REGISTER.md`](REGISTER.md) is the public record of how the data were checked, and it
@@ -208,9 +245,12 @@ The long form is [OEP 0](docs/oeps/oep-0000-process.md); the index is
   - Copy `docs/oeps/template.md` to `oep-NNNN-short-slug.md`, with the next free number.
   - Add it to the index, and to the roadmap's draft section (after the accepted
     proposals).
-  - Merge it early as `Draft`, from a `docs/oep-NNNN-…` branch.
-  - Remove an informal roadmap item only if the OEP covers it fully. Otherwise link the
-    OEP, state the partial coverage and keep the remaining work.
+  - List in its *Context* the open issues it will fix or that must be resolved first
+    (search them, and solprop's if it consumes the result).
+  - Open its tracking issue (OEP 0), and merge it early as `Draft`, from a
+    `docs/oep-NNNN-…` branch.
+  - Close an issue the OEP covers fully only when the OEP is `Final`. Otherwise link the
+    OEP from the issue and state what it leaves.
   - Reconcile these entries whenever the scope or status changes.
 - **An OEP stands alone.** It may cite:
   - optmat's and solprop's own docs, code, tests and proposals, and commits on their
@@ -260,7 +300,8 @@ The long form is [OEP 0](docs/oeps/oep-0000-process.md); the index is
   Report failures and gaps plainly.
 - **Finishing.** At `Final`:
   - each manual page the OEP produced ends with a link to it;
-  - its open questions move to the roadmap, to issues or to `open` register entries;
+  - its open questions move to issues or to `open` register entries;
+  - its tracking issue closes;
   - the `CHANGELOG.md` line cites it.
 
   A final OEP is history: the manual describes current behaviour.
@@ -399,6 +440,10 @@ The manual's conventions pages are the long form.
   copyright, and its `PROVENANCE.md` states the publisher's terms, or that it states
   none. **The package is self-contained:** it never downloads data at run time; what a
   model needs is shipped with it.
+- **Frozen fixtures:** `tests/data/solprop_*.json` record what solprop held before it
+  moved to optmat, and are neither edited nor regenerated: solprop now takes these values
+  from optmat, so re-running `tools/solprop_*.py` would compare optmat with itself. A
+  change to a model does not touch them.
 - **Generated files are never hand-edited;** re-run what writes them:
   - `uv.lock` (uv);
   - the docs build: `docs/_build/`, `docs/auto_gallery/`, `docs/api/generated/`,
@@ -409,22 +454,24 @@ The manual's conventions pages are the long form.
     `data/gas/` and `data/solid/` (`tools/fit/`);
   - test fixtures: `tests/data/public_api.json` (`tools/public_api.py`),
     `golden_models.json` and `golden_raman_identities.json` (`tools/golden_models.py`),
-    `solprop_*.json` (`tools/solprop_*.py`), `luna_master.json`
-    (`tools/luna_reference.jl`);
+    `luna_master.json` (`tools/luna_reference.jl`);
   - the manual's tables written by `--update-docs` (`tools/fit/nonlinear_support.py`,
     `tools/two_photon_tables.py`).
 
 ## Git and review
 
 - **Branches and worktrees:** all development happens on a topic branch in its own
   worktree. Create them without asking: name the branch for its topic (`data/<source>`,
-  `fit/<gas>`, `fix/...`, `feature/...`, `docs/...`; `docs/oep-NNNN-…` for an OEP draft
-  and `feature/oep-NNNN-…` for each of its phases) and put the worktree under
+  `fit/<gas>`, `fix/...`, `feature/...`, `docs/...`, `chore/...`; `docs/oep-NNNN-…` for
+  an OEP draft and `feature/oep-NNNN-…` for each of its phases) and put the worktree under
   `.claude/worktrees/` (ignored), or where your tool puts its worktrees. Continue in an
   existing branch/worktree when asked to. **The main checkout stays on `main`, clean:**
   other local projects build against it, so never edit files, switch branches or leave
-  work in it; its one use is to merge a finished branch. Changes reach GitHub as pull
-  requests, which CI checks.
+  work in it; its one use is to merge a finished branch. Changes reach `main` as pull
+  requests with green CI, or by a local merge when the maintainers ask for one.
+- **Before opening an issue or a pull request,** read [`CONTRIBUTING.md`](CONTRIBUTING.md):
+  search the issues, the pull requests and the OEPs, link what is related, and follow its
+  sections and labels.
 - **Review:** a pull request that changes data or models is reviewed for:
   - its register entries, and its errata with their evidence;
   - its extraction reproducing the files;
@@ -439,12 +486,11 @@ The manual's conventions pages are the long form.
 - **Versions:** never tag, release or change a version by hand; versions come from git
   tags.
 - **Coding agents:**
-  - never push;
+  - merge, push, tag or release only when asked or authorised, and do not ask again for
+    an already authorised action;
   - never run a destructive or history-rewriting command (`git reset --hard`,
     `git checkout .`, `git restore` over uncommitted changes, `git clean`,
     `git stash drop`, `git branch -D`, `git worktree remove --force`,
     `git commit --amend`, `git rebase`, a force push): these can destroy work that is
     not yours;
-  - create branches and worktrees freely (above); `fetch`, `pull` and `merge` into
-    `main` only when asked or authorised, and do not ask again for an already
-    authorised action.
+  - create branches and worktrees freely (above).