From PinPointStudio's preview handover, 28 August 2026, §5 — the two things from the preview investigation that generalise, raised for the joint review and for both conformance suites.
1. A library-issued ack is not an application ack
libppcp answers a consumer's stream_open on its own authority, before the embedding's code runs: peer_on_stream_open calls peer_stream_add and acks opened. So on 27–28 August, PinPointStudio's log read opened=1, refused=0 — from a peer that had just refused to produce anything on that Stream, because the application's own openStream was a duplicate the engine rejected under 5.1a.
⛔ Any conformance claim resting on "the peer said opened" is weaker than it looks, at both ends. It says the library parsed a frame. It says nothing about whether an application did anything.
2. Clause-by-clause spec review cannot find any of this
Nine defects across three repositories. Not one of them violates a clause. They are wrong counts, wrong sizes, wrong ordering, and swallowed errors:
| |
|---|
| An assignment after a throw | not a clause |
| A 35 kB payload against a 32 kB chunk | not a clause |
An openChannel that could only ever fail | not a clause |
A duplicate stream_open | not a clause |
A shed reaching back before opened_at | not a clause |
| One preview slot for two Sources | not a clause |
| A transfer table that never reclaims | not a clause |
⚠ Every one was found by running the thing and reading a device console — about ninety seconds, and it should have been the first thing anyone did. The same shape as #98 and #103, both of which a hardware run found and no review had.
What to add, and it is deliberately dull
Hold a continuous Stream open and assert a Capture actually arrives, and keeps arriving.
- Ours: a device-side conformance row that opens a Stream, runs it for a fixed interval, and asserts the count of Captures announced
present is what the rate says it should be — not zero, and not one. - Theirs: the receiving half, asserting frames assembled and not merely chunks accepted.
- ⚠ Nothing anywhere does this today.
docs/conformance/ppcp-conform.md and its libppcp counterpart check message shape and clause behaviour; neither holds a stream open and counts.
Both learnings belong in the joint review's ppcp-learnings.md — ⚠ which exists in neither this tree nor libppcp's, so where it lives is part of this item.
Exit criterion
A conformance row in this repository that fails if PreviewProducer stops producing, agreed with PinPointStudio so their suite carries its twin, and the two learnings written down somewhere both teams read.
From PinPointStudio's preview handover, 28 August 2026, §5 — the two things from the preview investigation that generalise, raised for the joint review and for both conformance suites.
1. A library-issued ack is not an application ack
libppcpanswers a consumer'sstream_openon its own authority, before the embedding's code runs:peer_on_stream_opencallspeer_stream_addand acksopened. So on 27–28 August, PinPointStudio's log readopened=1,refused=0— from a peer that had just refused to produce anything on that Stream, because the application's ownopenStreamwas a duplicate the engine rejected under 5.1a.⛔ Any conformance claim resting on "the peer said
opened" is weaker than it looks, at both ends. It says the library parsed a frame. It says nothing about whether an application did anything.2. Clause-by-clause spec review cannot find any of this
Nine defects across three repositories. Not one of them violates a clause. They are wrong counts, wrong sizes, wrong ordering, and swallowed errors:
openChannelthat could only ever failstream_openopened_at⚠ Every one was found by running the thing and reading a device console — about ninety seconds, and it should have been the first thing anyone did. The same shape as #98 and #103, both of which a hardware run found and no review had.
What to add, and it is deliberately dull
Hold a continuous Stream open and assert a Capture actually arrives, and keeps arriving.
presentis what the rate says it should be — not zero, and not one.docs/conformance/ppcp-conform.mdand its libppcp counterpart check message shape and clause behaviour; neither holds a stream open and counts.Both learnings belong in the joint review's
ppcp-learnings.md— ⚠ which exists in neither this tree norlibppcp's, so where it lives is part of this item.Exit criterion
A conformance row in this repository that fails if
PreviewProducerstops producing, agreed with PinPointStudio so their suite carries its twin, and the two learnings written down somewhere both teams read.