Changelog entries and the conformance workflow's lists move into files a change adds #632

Merged

dcharlot merged 1 commit from chore/shared-append-points-files into main 2026-11-05 02:51:53 -05:00

Conversation 0 Commits 1 Files changed 159 +5438 -1935

dcharlot commented 2026-11-05 01:41:47 -05:00

Owner

Copy link

Why

Every change to WAI appended to the same few lines. Its changelog entry went to the head of
## Unreleased in wai/CHANGELOG.md, and its CI went into the lists wai-conformance.yml
kept by hand: the trigger's extension paths, WAI_FEATURES and its two siblings, the binaries and tests
the verifiers' job builds first, one step per module, the features-alone loop, the integer
kernels' tests and the cargo-class corpora. Two branches open at once each added a line at
the same place, so any two of them conflicted, and they merged one at a time, each rebased
on the one before.

With this change, the changelog entry is a file of its own, and each of those list entries
lives in the file of the step, corpus or test it belongs to. The changelog and the
workflow's lists then no longer make two branches conflict, unless two pick the same file
name. Other files are still shared, and two changes can still conflict in them: "What stays
shared" below names them and says how to insert there.

What changes

Changelog entries are files of wai/changes/

• An entry is wai/changes/<yyyy-mm-dd>-<slug>.md, holding the entry exactly as the
  changelog would: a ### title, a blank line, then its text. wai/changes/README.md states
  the form.
• For a release, scripts/changelog-assemble.py --write renders the files into the head of
  ## Unreleased (newest date first, then by file name within a date) and removes them. The
  same files always give the same bytes. Without --write it prints what it would write, and
  --check checks every file.
• scripts/check-changelog-fragment.py is a new step of the repository checks. It fails a
  pull request that changes anything under wai/ and adds or edits no entry file directly
  in wai/changes/. A release, which renders the entries and removes their files, passes.
  A change with nothing to record ends one of its commit messages with the trailer line
  Changelog: none, exactly that line, in the message's trailer block. The check also fails, saying why, on an entry in a subdirectory, a malformed entry, or a range it
  cannot compare; it never passes unchecked. To make the comparison possible, the repository
  checks job now checks out the whole history (fetch-depth: 0).
• wai breaking reads the lines a change adds to entry files the same way it reads lines
  added to the changelog, so a **Breaking:** line in an entry acknowledges a break. The two
  public-text checks that exempt the changelog also exempt the entries waiting in
  wai/changes/.

The conformance workflow's lists and steps come from files of their own

• Each step of the independent verifiers is a file, verifiers/<name>.sh. The file holds the
  step's shell body, unchanged, under a header of # key: value lines (step:, order:,
  features:, paths:, bins:, release-features: and the rest).

• Each cargo-class corpus is a file, corpora/<name>.txt, that names its tool and directory.

• Each test of the fast integer kernels' steps tags itself in its first line:
  // wai-conformance: int-kernels, int-kernels-amd or int-kernels-release.

• When the workflow runs, scripts/wai-conformance-lists.py derives these lists from the
  files:

  • the three feature variables
  • the binaries and tests built first
  • the verifier steps and their order
  • the features-alone lists
  • the kernels' tests and features
  • the corpora and their features

  One workflow step runs every verifier file in order, each in its own log group. As with a
  failing step before, the first file that fails stops the job, and the error names that
  file.

• The workflow's trigger takes all of wai/extensions/**, and drops the per-extension lines
  that the step files now name. Its relevant job narrows that to the paths the workflow
  lists plus the paths the step files name. At run time the gate step reads the step
  headers itself, through scripts/pr-touches-paths.py --paths-from .github/wai-conformance/verifiers --wide 'wai/extensions/**'. The lists script's
  selftest and dry-run compute the same list by importing that script, and its check
  requires the gate to read the same step paths the lists script's paths command prints. A new step therefore brings
  the extension text it reads in its own file. For every file outside the two paths this
  change adds to the gate (.github/wai-conformance/** and
  scripts/wai-conformance-lists.py), the gate gives the same answer as before; for a file
  under those two, it now answers true.

• scripts/check-tests-in-ci.py counts a test as run when a step file names it or a step
  takes a tag the test carries. wai mcp's conformance tools read the verifier commands from
  the step files.

• .github/wai-conformance/README.md explains the files. python3 scripts/wai-conformance-lists.py dry-run prints what the workflow runs, run --only <name>
  runs one step as CI does, and check checks the files.

Pull requests opened before this lands

• Changelog. A pull request opened before the check reached main passes as it is,
  whether it edits the head of wai/CHANGELOG.md or has no entry at all. A pull request
  opened after the check reached main fails if it adds its entry to the head of
  ## Unreleased, and the message tells it to move the entry to a file of wai/changes/.
  (A pull_request run reads its workflow from the pull request's head, so a branch cut
  before the check reached main runs the check only once main is merged into it.) The check reads when the
  pull request was opened from the event payload (pull_request.created_at). It reads when
  the check reached main from the first-parent history of the pull request's base: the
  committer time of the first commit there whose tree holds the check, which is this
  change's merge commit, not the earlier commits of this branch. Until that merge the check
  is on no base, and every pull request counts as opened before it landed.

• The conformance workflow. A pull request that adds a step, a corpus or a kernel test to
  the hand lists of wai-conformance.yml conflicts with this change in that file. On rebase,
  it takes the workflow as this change leaves it and moves its addition into a file:

  • a step body goes into verifiers/<name>.sh, with its features and paths in the header
  • a corpus goes into corpora/
  • a kernel test gets its tag in its first line

  selftest then confirms that the hand lists' entries are all still there, and dry-run
  shows the new step.

What stays shared, and how to insert there

This change moves only the changelog entry and the conformance workflow's lists into files.
These are still edited by many changes, and two changes can still conflict in them:

• wai/wai-rs/Cargo.toml's [features], [[bin]] and [[test]] tables (a new verifier
  step usually adds a feature and a [[test]] entry here)
• wai/wai-rs/src/lib.rs's mod lines
• the rows of the tables of wai/wai-rs/src/codecs/registry.rs
• wai/.gitattributes
• the corpus table of wai/live-conformance/README.md, with the verifier commands under it
• the trigger of wai-conformance.yml, when a step's # paths: names a file under none of
  its paths (check fails such a step and names the path)

These files are grouped by topic, not sorted. Insert a new entry beside the entry it builds
on, never at the end, and never re-sort:

• a feature goes after the feature it depends on
• a target goes after its sibling
• a module goes after the module it extends
• a corpus row goes beside the row of the extension it builds on

Two changes that build on different entries then insert at different places and merge
cleanly. Two that build on the same entry insert at the same place and conflict; the one
that merges second resolves it by keeping both entries.

• A corpus whose bytes must never be converted gives its own directory a .gitattributes
  file (* -text), as wai/pin-conformance/ and wai/live-conformance/scene/ do, instead of
  adding a line to wai/.gitattributes.
• Generated files (wai/registry/capabilities.json, the table in wai/REGISTRY.md,
  wai/vocab/v2.*) are sorted by the export. On a conflict in one of them, take either side
  and run wai registry export again.

CLAUDE.md and wai/CONTRIBUTING.md state these rules.

How coverage is shown to be unchanged

• selftest --exact against the hand lists. .github/wai-conformance/baseline.json
  holds the lists wai-conformance.yml kept by hand on main at a223c597d. python3 scripts/wai-conformance-lists.py selftest --exact requires every derived list to equal its
  hand list. It also requires each verifier step to have the working directory and body of
  the hand list's step of the same name, in the same order, and names a step or a corpus the
  tree adds as an addition. It passes on this branch. The only additions are the two gate
  paths named under the dry-run diff below, which the baseline records as added. The
  repository checks run selftest on every pull request; it fails any change that drops an
  entry or a step of the hand lists.

• The dry-run diff. dry-run prints, in one stable form (flags and features sorted):
  every list, every verifier step, and the command lines of the integer kernels' steps, the
  corpus step, int-kernels-amd and the features-alone loop. The output for main and for
  this branch differs in one line. That line is the paths the gate runs on (the relevant
  job's list), which gain .github/wai-conformance/** and
  scripts/wai-conformance-lists.py, so a change to the files that now say what runs runs
  the workflow's jobs, as a change to the workflow file does. The trigger itself
  (on: pull_request: paths:) gains those two and wai/extensions/**, and drops the
  per-extension lines the step files now name; the gate's list still holds those paths,
  read from the step files. Every command line is the same. To reproduce:
  diff <(python3 scripts/wai-conformance-lists.py dry-run --ref a223c597d) <(python3 scripts/wai-conformance-lists.py dry-run).

• The workflow steps. Each step of the two changed workflow files, named or not, was
  compared with main's, by job and step name (a step with no name by its id or uses).
  Every step has the same name and body except those this change adds or rewrites:

  • repo-checks.yml: the checkout step (no name) checks out the whole history
    (fetch-depth: 0); and the new steps for the lists (their self-test and selftest)
    and for the changelog (its self-test, changelog-assemble.py --check and the pull
    request check).
  • wai-conformance.yml:
    • relevant: its gate step (id: gate, no name) passes --paths-from .github/wai-conformance/verifiers --wide 'wai/extensions/**' to
      scripts/pr-touches-paths.py.
    • cargo-classes: a step that makes sure python3 is present on the unix legs. The two
      integer-kernel steps take their tests and features from the tags. The corpus step,
      previously one step for the unix legs and one for Windows, is now one step for both
      that reads corpora/.
    • int-kernels-amd: its kernel step's features come from the int-kernels tag, as
      cargo-classes' kernel steps' do (features int-kernels --extra-features i32_forms),
      and its tests from the int-kernels-amd tag.
    • independent-verifiers: a new step derives the feature lists, and the build step
      builds the derived binaries and tests. One step that runs every file of verifiers/
      replaces the step per module.
    • features-alone: the Rust step also makes sure python3 is present, and the loop reads
      the derived lists.

  Each removed per-module step is now a file of verifiers/ with the same body, which
  selftest --exact checks.

• Self-tests that fail closed. scripts/wai-conformance-lists-selftest.sh checks that the
  derivation fails when coverage is lost:

  • it takes away a step, a feature, a tag and a corpus in turn, and requires each removal to
    fail
  • it adds a step, and requires the step's entries in every list
  • it plants a step and a corpus that run first, and requires selftest --exact to name
    each as one addition, with no step of the hand list changed or moved
  • it requires each malformed file to fail, with its reason

  Its checks hold whatever else the tree holds, so a pull request that adds a step passes
  them. scripts/changelog-fragments-selftest.sh builds scratch repositories and checks
  each rule of the changelog check and the assembler, including the transition and shallow
  clones. For the transition, main starts without the check, a branch adds it, and a pull
  request opened after that branch's commit but before its merge, and one opened after the
  merge, each edit the head of Unreleased: the first passes and the second fails.

What a contributor does now

• A change under wai/ adds wai/changes/<yyyy-mm-dd>-<slug>.md with its entry, and
  leaves the head of wai/CHANGELOG.md alone. If there is nothing to record, it ends a commit
  message with Changelog: none in the trailer block.
• A new verifier adds .github/wai-conformance/verifiers/<name>.sh: its body, with
  step:, order:, features: and paths: in the header. It adds no line to
  wai-conformance.yml, unless its paths: names a file under none of the trigger's paths.
  Any feature or [[test]] entry it needs goes into wai/wai-rs/Cargo.toml, beside its
  siblings.
• A new cargo-class corpus adds a file of .github/wai-conformance/corpora/. A new
  fast-kernel test carries // wai-conformance: int-kernels in its first line.
• In a shared file, it inserts beside the entry it builds on, never at the end.
• To check the work:
  • python3 scripts/wai-conformance-lists.py dry-run shows what runs
  • run --only <name> runs one step
  • check checks the step files
  • python3 scripts/changelog-assemble.py --check checks the entries

🤖 Generated with Claude Code

## Why Every change to WAI appended to the same few lines. Its changelog entry went to the head of `## Unreleased` in `wai/CHANGELOG.md`, and its CI went into the lists `wai-conformance.yml` kept by hand: the trigger's extension paths, `WAI_FEATURES` and its two siblings, the binaries and tests the verifiers' job builds first, one step per module, the features-alone loop, the integer kernels' tests and the cargo-class corpora. Two branches open at once each added a line at the same place, so any two of them conflicted, and they merged one at a time, each rebased on the one before. With this change, the changelog entry is a file of its own, and each of those list entries lives in the file of the step, corpus or test it belongs to. The changelog and the workflow's lists then no longer make two branches conflict, unless two pick the same file name. Other files are still shared, and two changes can still conflict in them: "What stays shared" below names them and says how to insert there. ## What changes ### Changelog entries are files of `wai/changes/` - An entry is `wai/changes/<yyyy-mm-dd>-<slug>.md`, holding the entry exactly as the changelog would: a `### ` title, a blank line, then its text. `wai/changes/README.md` states the form. - For a release, `scripts/changelog-assemble.py --write` renders the files into the head of `## Unreleased` (newest date first, then by file name within a date) and removes them. The same files always give the same bytes. Without `--write` it prints what it would write, and `--check` checks every file. - `scripts/check-changelog-fragment.py` is a new step of the repository checks. It fails a pull request that changes anything under `wai/` and adds or edits no entry file directly in `wai/changes/`. A release, which renders the entries and removes their files, passes. A change with nothing to record ends one of its commit messages with the trailer line `Changelog: none`, exactly that line, in the message's trailer block. The check also fails, saying why, on an entry in a subdirectory, a malformed entry, or a range it cannot compare; it never passes unchecked. To make the comparison possible, the repository checks job now checks out the whole history (`fetch-depth: 0`). - `wai breaking` reads the lines a change adds to entry files the same way it reads lines added to the changelog, so a `**Breaking:**` line in an entry acknowledges a break. The two public-text checks that exempt the changelog also exempt the entries waiting in `wai/changes/`. ### The conformance workflow's lists and steps come from files of their own - Each step of the independent verifiers is a file, `verifiers/<name>.sh`. The file holds the step's shell body, unchanged, under a header of `# key: value` lines (`step:`, `order:`, `features:`, `paths:`, `bins:`, `release-features:` and the rest). - Each cargo-class corpus is a file, `corpora/<name>.txt`, that names its tool and directory. - Each test of the fast integer kernels' steps tags itself in its first line: `// wai-conformance: int-kernels`, `int-kernels-amd` or `int-kernels-release`. - When the workflow runs, `scripts/wai-conformance-lists.py` derives these lists from the files: - the three feature variables - the binaries and tests built first - the verifier steps and their order - the features-alone lists - the kernels' tests and features - the corpora and their features One workflow step runs every verifier file in order, each in its own log group. As with a failing step before, the first file that fails stops the job, and the error names that file. - The workflow's trigger takes all of `wai/extensions/**`, and drops the per-extension lines that the step files now name. Its `relevant` job narrows that to the paths the workflow lists plus the paths the step files name. At run time the gate step reads the step headers itself, through `scripts/pr-touches-paths.py --paths-from .github/wai-conformance/verifiers --wide 'wai/extensions/**'`. The lists script's `selftest` and `dry-run` compute the same list by importing that script, and its `check` requires the gate to read the same step paths the lists script's `paths` command prints. A new step therefore brings the extension text it reads in its own file. For every file outside the two paths this change adds to the gate (`.github/wai-conformance/**` and `scripts/wai-conformance-lists.py`), the gate gives the same answer as before; for a file under those two, it now answers true. - `scripts/check-tests-in-ci.py` counts a test as run when a step file names it or a step takes a tag the test carries. `wai mcp`'s conformance tools read the verifier commands from the step files. - `.github/wai-conformance/README.md` explains the files. `python3 scripts/wai-conformance-lists.py dry-run` prints what the workflow runs, `run --only <name>` runs one step as CI does, and `check` checks the files. ### Pull requests opened before this lands - **Changelog.** A pull request opened before the check reached main passes as it is, whether it edits the head of `wai/CHANGELOG.md` or has no entry at all. A pull request opened after the check reached main fails if it adds its entry to the head of `## Unreleased`, and the message tells it to move the entry to a file of `wai/changes/`. (A pull_request run reads its workflow from the pull request's head, so a branch cut before the check reached main runs the check only once main is merged into it.) The check reads when the pull request was opened from the event payload (`pull_request.created_at`). It reads when the check reached main from the first-parent history of the pull request's base: the committer time of the first commit there whose tree holds the check, which is this change's merge commit, not the earlier commits of this branch. Until that merge the check is on no base, and every pull request counts as opened before it landed. - **The conformance workflow.** A pull request that adds a step, a corpus or a kernel test to the hand lists of `wai-conformance.yml` conflicts with this change in that file. On rebase, it takes the workflow as this change leaves it and moves its addition into a file: - a step body goes into `verifiers/<name>.sh`, with its features and paths in the header - a corpus goes into `corpora/` - a kernel test gets its tag in its first line `selftest` then confirms that the hand lists' entries are all still there, and `dry-run` shows the new step. ### What stays shared, and how to insert there This change moves only the changelog entry and the conformance workflow's lists into files. These are still edited by many changes, and two changes can still conflict in them: - `wai/wai-rs/Cargo.toml`'s `[features]`, `[[bin]]` and `[[test]]` tables (a new verifier step usually adds a feature and a `[[test]]` entry here) - `wai/wai-rs/src/lib.rs`'s `mod` lines - the rows of the tables of `wai/wai-rs/src/codecs/registry.rs` - `wai/.gitattributes` - the corpus table of `wai/live-conformance/README.md`, with the verifier commands under it - the trigger of `wai-conformance.yml`, when a step's `# paths:` names a file under none of its paths (`check` fails such a step and names the path) These files are grouped by topic, not sorted. Insert a new entry beside the entry it builds on, never at the end, and never re-sort: - a feature goes after the feature it depends on - a target goes after its sibling - a module goes after the module it extends - a corpus row goes beside the row of the extension it builds on Two changes that build on different entries then insert at different places and merge cleanly. Two that build on the same entry insert at the same place and conflict; the one that merges second resolves it by keeping both entries. - A corpus whose bytes must never be converted gives its own directory a `.gitattributes` file (`* -text`), as `wai/pin-conformance/` and `wai/live-conformance/scene/` do, instead of adding a line to `wai/.gitattributes`. - Generated files (`wai/registry/capabilities.json`, the table in `wai/REGISTRY.md`, `wai/vocab/v2.*`) are sorted by the export. On a conflict in one of them, take either side and run `wai registry export` again. `CLAUDE.md` and `wai/CONTRIBUTING.md` state these rules. ## How coverage is shown to be unchanged - **`selftest --exact` against the hand lists.** `.github/wai-conformance/baseline.json` holds the lists `wai-conformance.yml` kept by hand on main at a223c597d. `python3 scripts/wai-conformance-lists.py selftest --exact` requires every derived list to equal its hand list. It also requires each verifier step to have the working directory and body of the hand list's step of the same name, in the same order, and names a step or a corpus the tree adds as an addition. It passes on this branch. The only additions are the two gate paths named under the dry-run diff below, which the baseline records as added. The repository checks run `selftest` on every pull request; it fails any change that drops an entry or a step of the hand lists. - **The dry-run diff.** `dry-run` prints, in one stable form (flags and features sorted): every list, every verifier step, and the command lines of the integer kernels' steps, the corpus step, `int-kernels-amd` and the features-alone loop. The output for main and for this branch differs in one line. That line is the paths the gate runs on (the `relevant` job's list), which gain `.github/wai-conformance/**` and `scripts/wai-conformance-lists.py`, so a change to the files that now say what runs runs the workflow's jobs, as a change to the workflow file does. The trigger itself (`on: pull_request: paths:`) gains those two and `wai/extensions/**`, and drops the per-extension lines the step files now name; the gate's list still holds those paths, read from the step files. Every command line is the same. To reproduce: `diff <(python3 scripts/wai-conformance-lists.py dry-run --ref a223c597d) <(python3 scripts/wai-conformance-lists.py dry-run)`. - **The workflow steps.** Each step of the two changed workflow files, named or not, was compared with main's, by job and step name (a step with no name by its `id` or `uses`). Every step has the same name and body except those this change adds or rewrites: - `repo-checks.yml`: the checkout step (no name) checks out the whole history (`fetch-depth: 0`); and the new steps for the lists (their self-test and `selftest`) and for the changelog (its self-test, `changelog-assemble.py --check` and the pull request check). - `wai-conformance.yml`: - `relevant`: its gate step (`id: gate`, no name) passes `--paths-from .github/wai-conformance/verifiers --wide 'wai/extensions/**'` to `scripts/pr-touches-paths.py`. - `cargo-classes`: a step that makes sure python3 is present on the unix legs. The two integer-kernel steps take their tests and features from the tags. The corpus step, previously one step for the unix legs and one for Windows, is now one step for both that reads `corpora/`. - `int-kernels-amd`: its kernel step's features come from the `int-kernels` tag, as `cargo-classes`' kernel steps' do (`features int-kernels --extra-features i32_forms`), and its tests from the `int-kernels-amd` tag. - `independent-verifiers`: a new step derives the feature lists, and the build step builds the derived binaries and tests. One step that runs every file of `verifiers/` replaces the step per module. - `features-alone`: the Rust step also makes sure python3 is present, and the loop reads the derived lists. Each removed per-module step is now a file of `verifiers/` with the same body, which `selftest --exact` checks. - **Self-tests that fail closed.** `scripts/wai-conformance-lists-selftest.sh` checks that the derivation fails when coverage is lost: - it takes away a step, a feature, a tag and a corpus in turn, and requires each removal to fail - it adds a step, and requires the step's entries in every list - it plants a step and a corpus that run first, and requires `selftest --exact` to name each as one addition, with no step of the hand list changed or moved - it requires each malformed file to fail, with its reason Its checks hold whatever else the tree holds, so a pull request that adds a step passes them. `scripts/changelog-fragments-selftest.sh` builds scratch repositories and checks each rule of the changelog check and the assembler, including the transition and shallow clones. For the transition, main starts without the check, a branch adds it, and a pull request opened after that branch's commit but before its merge, and one opened after the merge, each edit the head of Unreleased: the first passes and the second fails. ## What a contributor does now - **A change under `wai/`** adds `wai/changes/<yyyy-mm-dd>-<slug>.md` with its entry, and leaves the head of `wai/CHANGELOG.md` alone. If there is nothing to record, it ends a commit message with `Changelog: none` in the trailer block. - **A new verifier** adds `.github/wai-conformance/verifiers/<name>.sh`: its body, with `step:`, `order:`, `features:` and `paths:` in the header. It adds no line to `wai-conformance.yml`, unless its `paths:` names a file under none of the trigger's paths. Any feature or `[[test]]` entry it needs goes into `wai/wai-rs/Cargo.toml`, beside its siblings. - **A new cargo-class corpus** adds a file of `.github/wai-conformance/corpora/`. **A new fast-kernel test** carries `// wai-conformance: int-kernels` in its first line. - **In a shared file**, it inserts beside the entry it builds on, never at the end. - **To check the work:** - `python3 scripts/wai-conformance-lists.py dry-run` shows what runs - `run --only <name>` runs one step - `check` checks the step files - `python3 scripts/changelog-assemble.py --check` checks the entries 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-11-05 01:41:47 -05:00

Changelog entries and the conformance workflow's lists move into files a change adds ... 946f3beda9

Every change to WAI added an entry at the head of wai/CHANGELOG.md, and every new module
appended to the hand-kept lists of .github/workflows/wai-conformance.yml. So any two
branches conflicted on those lines and had to merge one after another. This moves both into
files a change adds.

- Changelog entries: a change adds wai/changes/<yyyy-mm-dd>-<slug>.md holding the entry
  text. scripts/changelog-assemble.py renders the entries into CHANGELOG.md's Unreleased
  section for a release, in a stable order. scripts/check-changelog-fragment.py, run by
  repo-checks on every pull request, fails a pull request that changes wai/ and adds or
  edits no entry file directly in wai/changes/ (a release passes, and so does a commit
  with the trailer line "Changelog: none"). A pull request opened before the check reached
  main passes as it is; one opened after it that adds its entry to the head of Unreleased
  fails and is told where the entry goes. wai breaking reads breaking changes from entry
  files too.
- The conformance workflow: each per-module verifier step is a file in
  .github/wai-conformance/verifiers/, each corpus a file in corpora/, and the
  integer-kernel tests carry a tag line. scripts/wai-conformance-lists.py derives every
  list the workflow kept by hand (WAI_FEATURES, the union --bin and --test lists, the
  features-alone lists, the kernel and corpus steps) from those files when the workflow
  runs. Its `selftest --exact` holds the derived lists to the hand lists of the commit
  before this one, and its dry-run prints every command each job runs: the dry-runs before
  and after this change differ only in the gate's path list, which gains the two paths this
  change adds.
- What stays shared, and how to insert there, is written in wai/CONTRIBUTING.md and
  wai/changes/README.md: wai-rs Cargo.toml features and [[test]] entries, lib.rs, registry
  rows, wai/.gitattributes and the live corpus table take an insert beside the related
  entry, never at the end.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit 8951acabac into main 2026-11-05 02:51:53 -05:00

dcharlot referenced this pull request from a commit 2026-11-05 02:51:55 -05:00

Merge pull request 'Changelog entries and the conformance workflow's lists move into files a change adds' (#632) from chore/shared-append-points-files into main

dcharlot referenced this pull request 2026-11-05 04:24:25 -05:00

wai: one-way delivery — timeliness, rung price, cache authority and impression aggregates #633

dcharlot referenced this pull request 2026-11-05 04:24:44 -05:00

wai toolchain: wai.json's schema and version, MCP 2026-07-28, AGENTS.md in every template, WAI Studio in the quickstart archive, and one port table #634

dcharlot referenced this pull request 2026-11-05 04:25:07 -05:00

wai: the integer decode paths hold no floating point in their source, and read no JSON with a float parser #635

dcharlot referenced this pull request 2026-11-05 04:25:26 -05:00

wai: a channel's breaks marked in its HLS Media Playlist, and why a delivery took the route it took #636

dcharlot referenced this pull request 2026-11-05 04:25:43 -05:00

wai: bearer-receipts §13, reconciliations and holdings records over a return path of a few bytes #637

dcharlot referenced this pull request 2026-11-05 04:25:59 -05:00

wai: parameter sets — where a set is fetched, a successor coded against its predecessor, when a set is worth holding, who may read it, and a set verified piece by piece #638

dcharlot referenced this pull request 2026-11-05 04:26:16 -05:00

wai: neural-conformance's trained vector is trained and coded on generated pictures, and every vector has a licence record #639

dcharlot referenced this pull request 2026-11-05 04:26:37 -05:00

wai: the deterministic module profile, a checked subset of WebAssembly for the decoder modules a sink runs #640

dcharlot referenced this pull request 2026-11-05 04:27:10 -05:00

wai: an ad decision's consent signal and supply chain, bound into what the decider signs #641

dcharlot referenced this pull request 2026-11-05 04:27:27 -05:00

wai conform: JUnit and HTML reports, independent verifiers beside an implementation, the corpus union as one command, and wai doctor #642

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!632

No description provided.