feat(schema): add the parlay block and the veilid channel #14

Merged

peterswimm merged 1 commit from feat/veiled-parlay-block into main

2026-10-02 17:52:25 +00:00

peterswimm commented

2026-10-02 00:43:26 +00:00

Owner

Adds the parlay ForgeBlock and the veilid channel. This is the contract for veiled parlays: multi-party decisions whose ballots live on the Veilid DHT, with an attribution mode fixed at creation. The design, the four modes with what each can be forced to give up, and what veilid-core 0.5.7 does and does not guarantee are in docs/veiled_parlay.md.

Changes

schemas/forge_block.json 1.1: ParlayBlock, ParlayStatus, ParlayAttributionMode, ParlayTally, ParlayTransport, plus the union and discriminator entries.
schemas/frame_wire.json 1.4: ChannelType gains veilid.
openapi.yaml 0.61.0: a closed mirror of the five definitions, the parlay union entry, and the veilid channel.
schemas/index.json 1.5, CHANGELOG.md, and the new docs/veiled_parlay.md.

Enums follow the live database, not ritual-core/src/schema/tables.rs, which is stale:

status includes superseded;
the tally choices are approve/reject/abstain, with no block.

Tests

This repository has no test suite since test_frame_wire.py was retired. Contract tests live in ritual-engine's frame-wire-contract crate, and that crate needs a follow-up PR to re-vendor spec/ and add parlay cases. Before pushing, I checked both documents with jsonschema (Draft 2020-12) against the same payloads. Both accept:

an attributable parlay with vote buttons;
an unattributable parlay with a veilid transport and no buttons;
the superseded status.

Both reject:

vote buttons on unattributable and collective parlays;
an unknown mode;
a block tally key;
a threshold above 1;
a non-slug transport kind;
a missing tally;
an unknown property.

Spectral isn't installed on this machine, so spectral lint was not run.

Impact Statement

Existing features: no expected impact. The change is additive, and existing blocks and channels are unchanged.
Public APIs / contracts: a new block variant and a new channel value. Clients generated from the old schemas won't recognise either; rituals-chat and UDG PRs follow.
Schemas: forge_block 1.0 → 1.1, frame_wire 1.3 → 1.4, index 1.4 → 1.5, OpenAPI 0.60.0 → 0.61.0.
Data / artifacts: none here. The matching migration (core.parlay_attribution_modes, core.parlay_ballots, core.veilid_parlay_records) is a separate spel PR.
Integrations: veilid becomes a core.integrations row in the spel PR. ParlayTransport.kind is a registry slug per ADR-0004.
Mappings: the enums map 1:1 to the core.parlays.status and core.parlay_votes.vote CHECK constraints, and to the new attribution-mode registry.
Backward compatibility: every payload valid before is still valid. Vendored copies (ritual-engine frame-wire-contract, crates/frame-wire, ritual-core/schemas, rituals-chat vendor/api-spec) must be refreshed, or they will reject parlay blocks.

Adds the `parlay` ForgeBlock and the `veilid` channel. This is the contract for veiled parlays: multi-party decisions whose ballots live on the Veilid DHT, with an attribution mode fixed at creation. The design, the four modes with what each can be forced to give up, and what `veilid-core` 0.5.7 does and does not guarantee are in `docs/veiled_parlay.md`. ## Changes - `schemas/forge_block.json` 1.1: `ParlayBlock`, `ParlayStatus`, `ParlayAttributionMode`, `ParlayTally`, `ParlayTransport`, plus the union and discriminator entries. - `schemas/frame_wire.json` 1.4: `ChannelType` gains `veilid`. - `openapi.yaml` 0.61.0: a closed mirror of the five definitions, the `parlay` union entry, and the `veilid` channel. - `schemas/index.json` 1.5, `CHANGELOG.md`, and the new `docs/veiled_parlay.md`. Enums follow the live database, not `ritual-core/src/schema/tables.rs`, which is stale: - status includes `superseded`; - the tally choices are `approve`/`reject`/`abstain`, with no `block`. ## Tests This repository has no test suite since `test_frame_wire.py` was retired. Contract tests live in ritual-engine's `frame-wire-contract` crate, and that crate needs a follow-up PR to re-vendor `spec/` and add parlay cases. Before pushing, I checked both documents with `jsonschema` (Draft 2020-12) against the same payloads. Both accept: - an attributable parlay with vote buttons; - an unattributable parlay with a veilid transport and no buttons; - the `superseded` status. Both reject: - vote buttons on unattributable and collective parlays; - an unknown mode; - a `block` tally key; - a threshold above 1; - a non-slug transport kind; - a missing tally; - an unknown property. Spectral isn't installed on this machine, so `spectral lint` was not run. ## Impact Statement - **Existing features:** no expected impact. The change is additive, and existing blocks and channels are unchanged. - **Public APIs / contracts:** a new block variant and a new channel value. Clients generated from the old schemas won't recognise either; rituals-chat and UDG PRs follow. - **Schemas:** `forge_block` 1.0 → 1.1, `frame_wire` 1.3 → 1.4, index 1.4 → 1.5, OpenAPI 0.60.0 → 0.61.0. - **Data / artifacts:** none here. The matching migration (`core.parlay_attribution_modes`, `core.parlay_ballots`, `core.veilid_parlay_records`) is a separate spel PR. - **Integrations:** `veilid` becomes a `core.integrations` row in the spel PR. `ParlayTransport.kind` is a registry slug per ADR-0004. - **Mappings:** the enums map 1:1 to the `core.parlays.status` and `core.parlay_votes.vote` CHECK constraints, and to the new attribution-mode registry. - **Backward compatibility:** every payload valid before is still valid. Vendored copies (ritual-engine `frame-wire-contract`, `crates/frame-wire`, `ritual-core/schemas`, rituals-chat `vendor/api-spec`) must be refreshed, or they will reject `parlay` blocks.

peterswimm added 1 commit

2026-10-02 01:11:16 +00:00

feat(schema): add the parlay block and the veilid channel

PR policy check / policy-gate (pull_request) Failing after 1s

Details

CI / schema-registry (pull_request) Failing after 5s

Details

525f462b66

A parlay is a decision several parties make together, and until now no
surface could show one: there was no block for it and no channel for a
transport that carries ballots off-forge.

forge_block.json 1.1 adds the parlay variant. Its enums mirror the live
database, not ritual-core's stale row struct: status includes superseded,
and the tally's choices are approve, reject and abstain, without block.
The attribution mode is fixed when the parlay is created, and each mode is
documented with what it can be forced to give up. Vote buttons are
schema-enforced to attributable parlays: a forge surface always knows who
is speaking, so a ballot cast through one is attributable whatever the
parlay claims.

frame_wire.json 1.4 adds the veilid channel. Both changes are additive.
The OpenAPI mirror is closed and carries the same anyOf. Before any
citation went into docs/veiled_parlay.md, each statement about
veilid-core 0.5.7 was checked against that version's source.

peterswimm merged commit b2c6bb0e47 into main

2026-10-02 17:52:25 +00:00

peterswimm deleted branch feat/veiled-parlay-block

2026-10-02 17:52:25 +00:00

peterswimm referenced this pull request from a commit

2026-10-02 17:52:26 +00:00

Merge pull request 'feat(schema): add the parlay block and the veilid channel' (#14) from feat/veiled-parlay-block into main

peterswimm referenced this pull request

2026-10-06 15:14:40 +00:00

feat(schema): code, diff and progress blocks, block semantics, and the lens contract (#15) #17