wai: wai generate and wai score, and the instruction object of wai.generate.spectral (form v0) #197

Merged

dcharlot merged 12 commits from wai/generate-score-cli into main 2026-10-10 22:59:43 -04:00

Conversation 0 Commits 12 Files changed 25 +2265 -24

dcharlot commented 2026-10-09 10:21:52 -04:00

Owner

Copy link

Native pins for generated pictures and scores. wai generate and wai score make them with the reference code, and the payload of wai.generate.spectral gets a byte layout. A browser sink that makes the same pieces can then check every byte against a pin made natively. No library source changes, so the pins bind the shared browser binding pages already load.

• The payload of wai.generate.spectral (SPEC §5, Payload of wai.generate.spectral).
  • This completes the registration as §8 permits: the row named the generator and gave no byte layout.
  • The payload is an instruction object, form v0: one canonical JSON object with five members.
    • model: the model file's SHA-256.
    • prompt, seed and steps.
    • sizes: every size a sink may make.
  • Each object has exactly one serialization. Members are in ascending byte order with no whitespace, and the prompt is printable ASCII without " or \, so it needs no escape. Every value has a stated range. As a result, an envelope's content hash names the instructions.
  • A sink makes only the listed sizes, and only with that model. Conformance is generation-equivalence at each listed size. A sink that holds a size's SHA-256 does not present a picture that differs from it, and never accepts one on a 64-bit FNV-1a alone.
  • The registry row names the payload, §8 lists the completion, and REGISTRY.md's status note names it.
• The model is the parameter set; the envelope carries no pin. The model file is the generator's parameter set (§3.1), and model is its identity. An envelope that names the generator, as capability, fallback or WAI2 component, carries no prior, and a sink refuses one that does, even a pin over the very file model names. §3.1 says so beside the pin rules, and prior-carriage §7's row says the set is never pinned. No library source changes.
• The intent is create, and only create. A generator has no source to replicate or improve. An envelope that names the generator with any other intent is non-conforming, and wai wrap refuses replicate, improve, an open string or the empty string over it, as capability or as fallback.
• wai generate (feature generate):
  • makes a picture at any size form v0 allows and prints {w, h, bytes, sha256};
  • --instr makes a listed size from an object, reading the object as a sink does;
  • --write-instr writes the canonical object.
  • The model file is checked before the generator reads it, so a wrong file is refused instead of panicking.
• wai score build | render (feature score):
  • build writes a WSCR from integer note fields only (score §2.3). A fraction, an unknown member, a member given twice or a cut release is refused.
  • render prints samples, pcm_sha256, mixdown_blake3 and score_hash, and --pcm writes the samples. It refuses a contract of more than one channel or of another numeric profile, as build does.
  • A WSCR that declares more notes than its bytes hold is refused before the reader reserves room for them.
• wai wrap refuses a wai.generate.spectral payload, as capability or as fallback, that is not a form-v0 object, and any intent but create over it. This applies in every build.
• wai inspect and wai unwrap report every envelope or WAI2 component that names the generator: its payload (form v0, with the reader's reason), its intent and any pin, ✓ or ✗.
• The reader gives reasons. wai generate --instr, wai wrap, inspect and unwrap refuse an object with the code of the first rule it breaks (not_canonical, prompt_byte, seed_range, member_repeated, …). A member given twice is refused as such: JSON is read with every object's members distinct.
• Vectors:
  • tests/vectors/generate/sizes.json: the committed prompt at 256×128 and 640×320.
  • tests/vectors/generate/instr-v0.json: the object and the SHA-256 at each of its four listed sizes; twelve objects at the inclusive bounds of form v0, which a sink accepts, each with the SHA-256 of its first listed size (seed 0 and 2³² − 1, steps 1 and 64, an empty prompt, 256 bytes, 0x20 and 0x7E, JSON's structural characters, a side of 1, a side of 4096 and 2²³ pixels, 16 sizes, the w-then-h order); and 36 objects a sink refuses, each with the rule the reference reader finds broken first.
  • score-conformance/expected_hashes.json: gains pcm_sha256 for every vector.
  • score-conformance/notes/<name>.json: the authoring form, which wai score build turns back into the committed WSCR byte for byte. wai_score_vectors verify checks all of these.
• CI:
  • Both profiles of the integer-kernel steps build wai with generate,score and run tests/cli_generate_score.rs, which asserts each refusal's reason and makes and wraps every accepted object; tests/generate.rs holds the same lists to a second, independent statement of form v0. The two larger listed sizes run in the release step only, because they take seconds each in a debug build.
  • The wasm32 workflow runs wai-web/demo/verify_generate_wasm.mjs: the browser binding's generateSpectral at every pinned size (sizes.json, instr-v0.json's object and every accepted object) and ScoreSink over every score vector give the SHA-256 the native tools wrote. It now also triggers on wai/score-conformance/.

Pins (RGB8 SHA-256; prompt a calm spectral horizon, seed 7, steps 4, model sha256:963ee634…1504f9e):

size	sha256
96×96 (existing)	c0650ea4419bf6ba6697c7ccbe936bd2dc4c87ebb76ef781ea8175c59b1aad5d
256×128	6c7eabbc826affc752394fa67bf74e135331664d53edf13a4f6eabb9b1f80704
640×320	54bc40567935a8b264d1836bd94439623b233c3551b535ea54960f35327e5bf2
1280×720	909aa2d54cc1ab3a98912b173e5b031c8634a794b9ad58f0526a543b4cb7acc8
1920×1080	763e9f672810db934d8c492db77230d6d1e7ab1375c6ff1f076222fa4dfcc83a

Score pcm_sha256:

• scale: dc3c7ef8…5a025f
• chord: c4e9c4e9…8f79b7
• arp: b8dc096c…d80554

Every value above was made natively, and each equals what the shared browser binding computes for the same input.

Review round 2 (nine commits on 3770d1ab): the pin relation, the intent rule, inspect/unwrap findings, accepted objects at every bound with reasons for every refusal, the wasm32 pin check, the REGISTRY note, score render contract checks, duplicate members refused, the note-count test reaching the guard it names, and a scratch-file race between two concurrent tests. Each falsified where a test guards it:

• the quotation mark let into the prompt (the reason check fails: not_canonical, not prompt_byte), and steps capped at 63 (the accepted list fails);
• the intent rule disabled (improve written);
• the pin finding and the payload finding each disabled in inspect/unwrap;
• score render's contract checks disabled (a two-channel contract rendered);
• the strict JSON reader replaced by serde_json (a repeated start builds);
• the note-count guard removed (the crafted file now reaches the reservation: "byte stream truncated");
• one pin altered in a scratch copy of the vectors (verify_generate_wasm.mjs fails on it).

Checked locally on macOS arm64, at 4c09bea7:

• The link gate is GREEN. Its steps:
  • build and the library tests (797);
  • carriage;
  • the corpus loop, 21 of 21, with the score corpus checking pcm_sha256 and the notes files;
  • the integer-kernel step, 533 tests, among them cli_generate_score (14 passed, 1 ignored: the large sizes) and generate (4 passed, 1 ignored);
  • byte-exact, wai-web wasm32 and the neural gates.
• Targeted runs:
  • release: cli_generate_score 15 passed; generate 5 passed (the large sizes among them).
  • cli_wrap_intent without features: 9 passed.
  • verify_generate_wasm.mjs on a wasm32 node build of this tree: 35 checks pass.
• Falsified in the first round (one mutation each, the named test seen to fail, then restored):
  • w and h swapped in wai generate;
  • the canonical-bytes check dropped (fails both in the CLI test and in the featureless wrap test);
  • big-endian PCM;
  • a wrong pcm_sha256 and a drifted notes file (verify reports each);
  • a wrong small-size pin and a wrong large-size pin (the second caught in the release step);
  • the wrap check disabled.
• The pins bind the browser binding: git diff 248846f1 HEAD is empty for src/generate.rs, src/score, src/world and wai-web/src.
• Repository checks: public text (names and comparative prose, each changed file), workflow concurrency. The CHANGELOG's seven comparative-prose hits are all on main already; none is new.

The forge CI runs on this pull request.

🤖 Generated with Claude Code

Native pins for generated pictures and scores. `wai generate` and `wai score` make them with the reference code, and the payload of `wai.generate.spectral` gets a byte layout. A browser sink that makes the same pieces can then check every byte against a pin made natively. No library source changes, so the pins bind the shared browser binding pages already load. - **The payload of `wai.generate.spectral`** (SPEC §5, *Payload of `wai.generate.spectral`*). - This completes the registration as §8 permits: the row named the generator and gave no byte layout. - The payload is an **instruction object, form v0**: one canonical JSON object with five members. - `model`: the model file's SHA-256. - `prompt`, `seed` and `steps`. - `sizes`: every size a sink may make. - Each object has exactly one serialization. Members are in ascending byte order with no whitespace, and the prompt is printable ASCII without `"` or `\`, so it needs no escape. Every value has a stated range. As a result, an envelope's content hash names the instructions. - A sink makes only the listed sizes, and only with that model. Conformance is generation-equivalence at each listed size. A sink that holds a size's SHA-256 does not present a picture that differs from it, and never accepts one on a 64-bit FNV-1a alone. - The registry row names the payload, §8 lists the completion, and REGISTRY.md's status note names it. - **The model is the parameter set; the envelope carries no pin.** The model file is the generator's parameter set (§3.1), and `model` is its identity. An envelope that names the generator, as capability, fallback or `WAI2` component, carries no `prior`, and a sink refuses one that does, even a pin over the very file `model` names. §3.1 says so beside the pin rules, and prior-carriage §7's row says the set is never pinned. No library source changes. - **The intent is `create`, and only `create`.** A generator has no source to replicate or improve. An envelope that names the generator with any other intent is non-conforming, and `wai wrap` refuses `replicate`, `improve`, an open string or the empty string over it, as capability or as fallback. - **`wai generate`** (feature `generate`): - makes a picture at any size form v0 allows and prints `{w, h, bytes, sha256}`; - `--instr` makes a listed size from an object, reading the object as a sink does; - `--write-instr` writes the canonical object. - The model file is checked before the generator reads it, so a wrong file is refused instead of panicking. - **`wai score build | render`** (feature `score`): - `build` writes a `WSCR` from integer note fields only (score §2.3). A fraction, an unknown member, a member given twice or a cut release is refused. - `render` prints `samples`, `pcm_sha256`, `mixdown_blake3` and `score_hash`, and `--pcm` writes the samples. It refuses a contract of more than one channel or of another numeric profile, as `build` does. - A `WSCR` that declares more notes than its bytes hold is refused before the reader reserves room for them. - **`wai wrap`** refuses a `wai.generate.spectral` payload, as capability or as fallback, that is not a form-v0 object, and any intent but `create` over it. This applies in every build. - **`wai inspect` and `wai unwrap`** report every envelope or `WAI2` component that names the generator: its payload (form v0, with the reader's reason), its intent and any pin, ✓ or ✗. - **The reader gives reasons.** `wai generate --instr`, `wai wrap`, `inspect` and `unwrap` refuse an object with the code of the first rule it breaks (`not_canonical`, `prompt_byte`, `seed_range`, `member_repeated`, …). A member given twice is refused as such: JSON is read with every object's members distinct. - **Vectors:** - `tests/vectors/generate/sizes.json`: the committed prompt at 256×128 and 640×320. - `tests/vectors/generate/instr-v0.json`: the object and the SHA-256 at each of its four listed sizes; twelve objects at the inclusive bounds of form v0, which a sink accepts, each with the SHA-256 of its first listed size (seed 0 and 2³² − 1, steps 1 and 64, an empty prompt, 256 bytes, 0x20 and 0x7E, JSON's structural characters, a side of 1, a side of 4096 and 2²³ pixels, 16 sizes, the w-then-h order); and 36 objects a sink refuses, each with the rule the reference reader finds broken first. - `score-conformance/expected_hashes.json`: gains `pcm_sha256` for every vector. - `score-conformance/notes/<name>.json`: the authoring form, which `wai score build` turns back into the committed `WSCR` byte for byte. `wai_score_vectors verify` checks all of these. - **CI:** - Both profiles of the integer-kernel steps build `wai` with `generate,score` and run `tests/cli_generate_score.rs`, which asserts each refusal's reason and makes and wraps every accepted object; `tests/generate.rs` holds the same lists to a second, independent statement of form v0. The two larger listed sizes run in the release step only, because they take seconds each in a debug build. - The wasm32 workflow runs `wai-web/demo/verify_generate_wasm.mjs`: the browser binding's `generateSpectral` at every pinned size (sizes.json, instr-v0.json's object and every accepted object) and `ScoreSink` over every score vector give the SHA-256 the native tools wrote. It now also triggers on `wai/score-conformance/`. **Pins** (RGB8 SHA-256; prompt `a calm spectral horizon`, seed 7, steps 4, model `sha256:963ee634…1504f9e`): | size | sha256 | |---|---| | 96×96 (existing) | `c0650ea4419bf6ba6697c7ccbe936bd2dc4c87ebb76ef781ea8175c59b1aad5d` | | 256×128 | `6c7eabbc826affc752394fa67bf74e135331664d53edf13a4f6eabb9b1f80704` | | 640×320 | `54bc40567935a8b264d1836bd94439623b233c3551b535ea54960f35327e5bf2` | | 1280×720 | `909aa2d54cc1ab3a98912b173e5b031c8634a794b9ad58f0526a543b4cb7acc8` | | 1920×1080 | `763e9f672810db934d8c492db77230d6d1e7ab1375c6ff1f076222fa4dfcc83a` | Score `pcm_sha256`: - scale: `dc3c7ef8…5a025f` - chord: `c4e9c4e9…8f79b7` - arp: `b8dc096c…d80554` Every value above was made natively, and each equals what the shared browser binding computes for the same input. **Review round 2** (nine commits on `3770d1ab`): the pin relation, the intent rule, `inspect`/`unwrap` findings, accepted objects at every bound with reasons for every refusal, the wasm32 pin check, the REGISTRY note, `score render` contract checks, duplicate members refused, the note-count test reaching the guard it names, and a scratch-file race between two concurrent tests. Each falsified where a test guards it: - the quotation mark let into the prompt (the reason check fails: `not_canonical`, not `prompt_byte`), and `steps` capped at 63 (the accepted list fails); - the intent rule disabled (`improve` written); - the pin finding and the payload finding each disabled in `inspect`/`unwrap`; - `score render`'s contract checks disabled (a two-channel contract rendered); - the strict JSON reader replaced by `serde_json` (a repeated `start` builds); - the note-count guard removed (the crafted file now reaches the reservation: "byte stream truncated"); - one pin altered in a scratch copy of the vectors (`verify_generate_wasm.mjs` fails on it). **Checked locally on macOS arm64, at `4c09bea7`:** - **The link gate is GREEN.** Its steps: - build and the library tests (797); - carriage; - the corpus loop, 21 of 21, with the score corpus checking `pcm_sha256` and the notes files; - the integer-kernel step, 533 tests, among them `cli_generate_score` (14 passed, 1 ignored: the large sizes) and `generate` (4 passed, 1 ignored); - byte-exact, `wai-web` wasm32 and the neural gates. - **Targeted runs:** - release: `cli_generate_score` 15 passed; `generate` 5 passed (the large sizes among them). - `cli_wrap_intent` without features: 9 passed. - `verify_generate_wasm.mjs` on a wasm32 node build of this tree: 35 checks pass. - **Falsified in the first round** (one mutation each, the named test seen to fail, then restored): - `w` and `h` swapped in `wai generate`; - the canonical-bytes check dropped (fails both in the CLI test and in the featureless wrap test); - big-endian PCM; - a wrong `pcm_sha256` and a drifted notes file (`verify` reports each); - a wrong small-size pin and a wrong large-size pin (the second caught in the release step); - the wrap check disabled. - **The pins bind the browser binding:** `git diff 248846f1 HEAD` is empty for `src/generate.rs`, `src/score`, `src/world` and `wai-web/src`. - **Repository checks:** public text (names and comparative prose, each changed file), workflow concurrency. The CHANGELOG's seven comparative-prose hits are all on `main` already; none is new. The forge CI runs on this pull request. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 2 commits 2026-10-09 10:21:52 -04:00

wai: wai generate and wai score build|render, with native pins a sink checks against ... a220d16a48

`wai generate` makes a wai.generate.spectral picture with the reference generator at
any size and prints its SHA-256; with --instr it makes a listed size of an instruction
object of form v0, which it reads as a sink does, and --write-instr writes one.
`wai score build` writes a WSCR from integer note fields only; `wai score render`
prints samples, pcm_sha256, mixdown_blake3 and score_hash, and --pcm writes the samples.

Vectors: tests/vectors/generate/sizes.json (256x128, 640x320) and instr-v0.json (the
object, its four listed sizes and 28 objects a sink refuses); score-conformance gains
pcm_sha256 for every vector and notes/<name>.json, the authoring form, which
`wai score build` turns back into the committed WSCR byte for byte. Every pin was made
natively and equals the shared browser binding's output.

`wai wrap` refuses a wai.generate.spectral payload that is not a form-v0 object, in
every build. No library source changes.

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

wai SPEC §5: the payload of wai.generate.spectral is an instruction object (form v0) ... 3770d1ab8e

The registration is completed as §8 permits: the row named the generator and no byte
layout. The payload is one canonical JSON object naming the model by its SHA-256 and
giving the prompt, the seed, the steps and every size a sink makes, each within stated
bounds and with one serialization per object, so an envelope's content hash names the
instructions. A sink makes only listed sizes, with that model only; conformance is
generation-equivalence at each listed size, and a sink holding a size's SHA-256 does
not present a picture that differs or accept one on a 64-bit FNV-1a alone. The
envelope's intent is `create`: a generator does not back `replicate` (§7), and this
keeps that rule.

The registry row names the payload; §8 lists the completion. score §2.3 documents the
integer authoring form `wai score build` reads, and §4 the pcm_sha256 every vector now
states. CI builds the `wai` binary with `generate` and `score` in both profiles of the
integer-kernel steps and runs tests/cli_generate_score.rs there; the two larger listed
sizes of instr-v0.json run in the release step.

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

dcharlot referenced this pull request 2026-10-09 16:25:55 -04:00

wai: integer-operators (Draft), the operator set wai-ops/1, with its payload text in integer-payloads #202

dcharlot added 9 commits 2026-10-09 17:24:05 -04:00

wai cli tests: the two instr_sizes callers each write their own object file ... 35debe1706

instr_makes_the_listed_small_sizes and instr_makes_the_listed_large_sizes run at
once in the release step, and both removed and rewrote one scratch file,
object.instr, while the other's `wai generate --instr` children read it. A remove
or a truncating write landing as a child opened the file would refuse the object
and fail the test. Each caller now names its own file.

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

wai cli tests: the note-count guard is what refuses the crafted WSCR ... 0d123ab7f2

score_render_refuses_a_note_count_its_bytes_cannot_hold wrote a file with no
contract section, so the reader refused it with MissingSection(0x01) before
parse_notes reserved anything, guard or no guard: the test checked only which
message came first. The file now carries a well-formed contract (section 0x01) and
a notes section of only the count (0x02), and the same file declaring no notes is
shown to render, so without the guard the reader reaches Vec::with_capacity.

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

wai score render: refuse a contract that is not one channel of wai.det.fixed64 ... 887c99a61f

render printed "channels":2 beside a mono mixdown of `duration` samples when a WSCR's
contract said two channels, and rendered a contract whose numeric profile was
wai.det.float64; a verifier following SPEC §7 Digests would read that PCM as stereo
frames. render now refuses both, as build refuses to write them.
score_render_refuses_a_contract_it_does_not_render patches the committed scale.wscr
in place for each case.

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

wai score build: refuse a member given twice in the authoring form ... 95fa7244f6

The authoring form (score §2.3) is the definition, yet a note holding both
"start":0 and "start":5 built with start 5 (serde_json keeps the last value) and
the same hash as a note with start 5 alone; another JSON reader could keep the
first. wai_cli/strict_json.rs reads JSON with every object's members distinct and
refuses a repeat, and build reads its document through it. Two refused cases are
added: a note field and a document member, each given twice.

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

wai generate.spectral form v0: accepted objects at every bound, and each refusal's reason ... f0107b07b8

instr-v0.json had one accepted object and 28 refused ones, none at an inclusive
bound, so a second sink stricter by one passed every vector; and the CLI test held
only that each object was refused, not why, so a rule relaxed (a quotation mark let
into the prompt) stayed green while the canonical-bytes check refused the object
in its place.

- The reader (wai_cli/instr.rs) refuses with a reason code, the first rule broken
  in a stated order; a member given twice is refused as such (strict_json).
- The vector gains twelve accepted objects (seed 0 and 2^32 - 1, steps 1 and 64,
  an empty prompt, 256 bytes, 0x20 and 0x7e, JSON's structural characters, a side of
  1, a side of 4096 and 2^23 pixels, 16 sizes, the w-then-h order), each with the
  SHA-256 of its first listed size made natively; eight more refused objects (types,
  a fraction in a size, a negative side, an escaped line feed, a backslash, cut-short
  JSON); and a reason for every refused object.
- tests/cli_generate_score.rs asserts each refusal's reason through `wai generate
  --instr` and `wai wrap`, and makes and wraps every accepted object.
- tests/generate.rs states form v0 a second time, independently of the reader, and
  holds the object, the accepted and the refused lists to it, making each accepted
  object's output with the library.

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

wai generate.spectral: the generator's envelope carries intent create, and wrap writes no other ... da03ef1524

SPEC §5 said the envelope's intent is `create`, but `wai wrap` refused only
`replicate` and wrote wai.generate.spectral envelopes with `--intent improve` or
`--intent banana`, and the non-conforming list did not mention intent. The
sentence is now a rule: an envelope that names the generator, as capability or
fallback, carries `create`, one with another intent is non-conforming, and wrap
refuses any other. wrap_writes_the_generator_only_with_intent_create covers
improve, an open string, a case variant, the empty string and the fallback.

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

wai generate.spectral: the model is the parameter set, so the envelope carries no pin; inspect and unwrap report the payload ... 7e3b883074

Form v0 names the model inside the payload by the SHA-256 of one file, and SPEC §5
never said how that relates to §3.1's parameter-set pin, which governs every
GenerativeDeterministic capability: whether a generate envelope carries a pin, or
which wins when a pin and `model` disagree. The library registers the set as
several files, so a form-less pin over the very file `model` names would be
refused form_required. SPEC §5 now states the relation: the model file is the
parameter set and `model` its identity; an envelope that names the generator
carries no `prior` and a sink refuses one that does, whatever it names. §3.1 says
so beside the pin rules, the non-conforming list names it, and prior-carriage §7's
row says the set is never pinned and names the file. No library source changes.

`wai inspect` and `wai unwrap` reported a generate envelope with a corrupt
payload as conforming ("component roles ✓", no payload line). They now report
the payload (form v0, with the reader's reason), the intent and any pin of every
envelope or WAI2 component that names the generator, ✓ or ✗; inspect's verdict
says the envelope does not conform. inspect_and_unwrap_report_the_generators_envelope
covers a prompt byte changed in place, the intent improve, a pin over the model
file itself, and a WAI2 component with and without a pin.

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

wai REGISTRY: the status note names wai.generate.spectral among the registrations v0.4.0 completes ... cdc351b33c

The hand-written Status note listed the integer codecs whose registrations v0.4.0
completes and left out wai.generate.spectral, which SPEC §8 now says §5 completes.
The note sits outside the generated region the library test compares.

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

wai-web wasm32 CI: the browser generator and score synth make every native pin ... 4c09bea76a

The CHANGELOG said every pin equals the shared browser binding's output, and the
browser sink's form-v0 reading has no CI of its own, yet wai-web-wasm.yml ran no
generate or score check. demo/verify_generate_wasm.mjs runs generateSpectral at
every size the generate vectors pin (sizes.json, instr-v0.json's four listed sizes,
and the first listed size of each object at a bound of form v0), checks each
object names the committed model, and runs ScoreSink over every score-conformance
vector for its pcm_sha256, mixdown hash and score hash. The workflow runs it on the
node build and now also triggers on wai/score-conformance/. 35 checks pass locally
on a wasm32 build of this tree.

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

dcharlot added 1 commit 2026-10-10 17:23:08 -04:00

Merge origin/main into wai/generate-score-cli ... 815f3fb8c2

Brings in #200 (HTTP receipts and keys) and #206 (wai-ops) among the rest
of main. One conflict, wai/CHANGELOG.md: both sides added entries at the
top of v0.4.0. Kept every entry; this branch's "Generated pictures and
scores" stays on top as the newest, main's entries follow unchanged.

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

dcharlot referenced this pull request from a commit 2026-10-10 17:26:53 -04:00

Merge wai/generate-score-cli (with main) into wai/reach-builds

dcharlot referenced this pull request from a commit 2026-10-10 22:23:54 -04:00

Merge wai/reach-builds (with #197 and main) into wai/d1-record-true

dcharlot referenced this pull request from a commit 2026-10-10 22:24:07 -04:00

Merge wai/d1-record-true (with #205, #197 and main) into wai/w4-4-staged-packages

dcharlot merged commit a4490cf89e into main 2026-10-10 22:59:43 -04:00

dcharlot referenced this pull request from a commit 2026-10-10 22:59:45 -04:00

Merge pull request 'wai: `wai generate` and `wai score`, and the instruction object of wai.generate.spectral (form v0)' (#197) from wai/generate-score-cli into main

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!197

No description provided.