Sloppy Voice DevelopersSloppy Voice ↗

Validation and delivery

Document: SPEC-007. Revision: 0.14. Date: 2026-10-25. Lifecycle: Partially approved under delegated decision D-024; V1 resolution sections are active, later scope remains Draft. Supersedes: none.

Approved video-delivery successor — D-167

D-167/SPEC-024 refines A-49: measure video/presentation-sound synchronization separately from best-effort microphone alignment, plus actual cadence, latency, corruption and held-frame duration. A-29 retains hard cutoff tests for native adapters; managed presentations report provider closure/pending enforcement and the explicit partition limitation. Native and managed rate enforcement claims are tested separately. A 3 fps adaptation floor is a degraded state, not a passing gaming-quality result. See SPEC-024.

The human has approved the early test population/domain sequence in D-007 and the V1 feature/account/device-loss profile in D-020–D-022. Detailed stage allocations and numerical performance thresholds below remain PROPOSED unless tied to an accepted decision. No implementation is authorised by this document alone.

Delivery sequence

StageScope and exit conditionStatus
Specification reviewResolve relevant decisions; approve detailed protocol and client behaviour before implementationConfirmed workflow
Feasibility workOnce authorised, prove global PTT on tester platforms, encrypted voice through candidate media, hard mute, and the protocol's hosting fitProposed
Test version 1One domain, 3–10 human testers in one voice room with basic text; KDE Wayland and Windows testers; no screen-sharing requirement; web client strongly desiredConfirmed test scope and priorities
Test version 2Add a second independently configured domain and test federated identities in a hosted roomConfirmed next test scope
Usable gaming milestoneFederated rooms, reliable PTT voice, room text, E2EE DMs/direct calls, and screen sharingConfirmed priority; exact release contents need review
Meeting milestoneMeeting profile, collaborative whiteboard, webcam lip sync, and agreed meeting controlsRequired product capabilities; later sequencing proposed
Independent-operation milestoneDocumented alternative deployment, self-hosted media, compatibility tests, operational readiness, and supported desktop coverageRequired outcomes; grouping and timing proposed

Test version 1 exercises PTT, local mute/gain, moderator mute/shared gain, permission changes, audio device changes, and reconnect. D-010/D-011 confirm KDE Wayland and Windows testers plus basic room text; D-012 establishes focus-only browser PTT with stop on focus loss. Exact desktop/browser versions remain open; the web client is a strong first-version goal rather than a confirmed hard gate. D-020 selects an encrypted private room, one active device per account, and unformatted text messages with reconnect history. Editing/deletion, attachments, richer text and multi-device use follow later. D-021 selects administrator-issued account invitations with tester-chosen passwords. D-022 accepts unrecoverable older history after loss of the only device/keys in V1; login recovery remains separate. A desktop and browser using the same account cannot silently bypass the single-active-device limit.

Test version 2 should use distinct domain identities and signing/configuration state even if both deployments share one cloud account. Verify that domain A can host users from B and vice versa, that remote users need no second login account, and that domain B's admin status does not grant authority in A's room. Include domain refusal, home-domain outage, and room-host outage.

The 3–10-user cohort is an initial human test target, not a production concurrency limit or a claim of capacity. Larger registered-user counts, room sizes, simultaneous media, regions, and operating budget remain open. Automated load tests cannot replace human audio/PTT testing; human testing cannot establish unmeasured production scale.

Requested extensions under review

D-044–D-048 add linked devices/recovery, explicit voice movement and configurable keyboard/mouse/joystick PTT. Their implementation profiles are SPEC-011/012 and SPEC-005's selected input profile. A-33–A-37 apply when these features are delivered; they do not describe current alpha results or silently postpone D-007's second-domain milestone. Device/recovery gates replace A-32's single-device/no-recovery expectations only for the approved successor; invitation/password admission and access restrictions remain regression requirements. A-32 remains a regression fixture for legacy one-device accounts; the successor adds A-33–A-35 without claiming platform acceptance.

D-048 requires real joystick acceptance before leaving the testing phase. Use the human's ProtoArc mouse button 4 on KDE and Windows as the immediate mouse fixture. Joystick model and availability are pending; mocked input and compiled helpers cannot close this gate. Record exact hardware/software and verify the physical button rather than assuming numbering across APIs.

Milestone applicability

This is the proposed detailed allocation of scenarios to the accepted delivery sequence. Required means a gate for the stated delivered scope; Desired means absence is a recorded gap but is not itself a failed milestone; Later means no early implementation claim or pass is implied. A delivered optional feature must pass its applicable security/correctness tests. Later is a proposed schedule unless a human decision explicitly defers that feature. Existing applicable cases remain regression gates when later capabilities are added.

ScenariosV1V2First additional/full obligation
A-01, A-25, A-26Required specification/ownership checksRequiredEvery implemented change
A-21Required protocol assessment before protocol implementationReassess if profile changesVersioned profile and independent conformance
A-02LaterRequired in both host directionsGaming retains federation cases
A-03Required Workers plus selected external-media pathSame path plus two domainsIndependent-operation stage: alternate control deployment and managed/self-hosted media
A-04Required private combined room and disabled-capability behaviourSameGaming: supported ordinary presets; meeting: meeting preset
A-05Later; room E2EE tested separatelyLaterGaming: local/foreign DMs, offline delivery and direct calls
A-06Required design preserves ordinary-account automation; no bot SDK/service gateSameNoninteractive credential/provisioning delivery stage OPEN under Q-29
A-07, A-08, A-09, A-10, A-11Required for supported devices/media/rolesRequired across domainsExtend to each added platform, audio role and device capability
A-12LaterLaterGaming: screen/window sharing; audio scope follows Q-24
A-13, A-14LaterLaterMeeting: boards, encrypted-operation evidence and webcam sync
A-15Required local durability/retry/reconnectAdd federation retriesApply to every new durable operation
A-16Required private E2EE mode and rejection of mode mutationSameGaming: both access types, defaults and explicit opposite-mode choices
A-17Required measurements; any pass requires resolved applicable thresholds/fixtureRequired cross-domain fixtureAdd presentation and meeting metrics at their stages
A-18, A-23Required actual human cohort and KDE Wayland/Windows evidenceRequired second-domain extensionRetain earlier evidence and rerun affected regressions
A-19Later; record interim publication/deployment stateSameIndependent operation: selected licences, public sources/specs and deployment/recovery
A-20Required KDE Wayland/Windows subsetSameGNOME stage OPEN; macOS later; full matrix before full-product completion
A-22Required gaming walkthrough for delivered scopeSame with federationOpen-source/corporate walkthrough scope/stage OPEN
A-24Desired web delivery; required if deliveredSame priority unless changedEach delivered browser/version must conform
A-27Required private admission, first/returning-member history intervalsAdd foreign-member casesGaming: public listing/self-join and both access bundles
A-28Required text/live membership and device-removal boundaries for V1Add foreign devicesMulti-device cases when supported; extra modalities at their stages
A-29Required active-stream mute, failure and lease testsAdd federation/control partitionsRepeat for every supported adapter and audio role
A-30Later; no backup/restore support or recovery claimSameFull stale-snapshot restore drill before restore support/independent-operation acceptance
A-31Same Desired delivery status as A-24; local origin/credential cases if deliveredRequired foreign-origin cases if web deliveredSupported independent web origins under selected routing profile
A-32Required V1 invitation/password/device/key-loss profileSame across foreign-room participationRevisit profile when recovery/multi-device features are introduced

The two-active-publishing-device variant of A-10 is not a V1 gate: V1 rejects a second active device and tests revocation of its supported single device. D-046's successor permits several signed-in devices but one active voice client. Its A-10 extension tests account-wide mute across all devices, simultaneous-publication attempts and handover; it must not require two authorised active publishers. Trust/history/epoch cases become required with linked devices. Detailed test-message edit/delete and historical revision cases apply when those operations are introduced, while the V1 read/rejoin interval cases already apply.

Acceptance scenarios

All scenarios describe required/proposed validation work, not tests already run.

IDScenario and observable pass condition
A-01A feature change or bug fix identifies its active specification, decision status, and validation; supersession links resolve without contradictory active rules.
A-02Users from two independent domains join either host's room with existing identities; unauthorised role claims and blocked domains are rejected.
A-03A reference server runs on Workers with external media; documented alternative control hosting and self-hosted media satisfy the same applicable protocol tests.
A-04Text, voice, combined, and meeting room configurations expose only enabled capabilities; reading text never starts microphone/camera/screen capture.
A-05Direct messages deliver across domains and after recipient reconnect; direct calls establish; transport/host/media-service captures contain no decryptable content without participant keys. Include negative tests for key substitution, replay, and downgrade.
A-06An ordinary authorised account operates through noninteractive protocol access; it has no implicit bot privileges. Detailed bot UX is not required initially.
A-07Each supported desktop receives press/release events while a supported game is focused; lock, suspend, device/hotkey loss, and leaving/switching the active voice session stop transmission. Text-view navigation preserves the original voice target. Switching voice while held requires a fresh press after readiness. Samples outside permitted intervals are not encoded for sending.
A-08D-105 supersedes the earlier proposed domain restriction: channel mode inherits or explicitly overrides server policy; personal enabled PTT always requires PTT. Mandatory effective mode excludes voice activation and changes stop incompatible publication. Test malicious publishers separately; physical-input attestation is not claimed.
A-09With three users, A's local mute/gain of B changes only A's playback. A shared gain change is applied by all conforming listeners, with personal adjustments preserved. A local mute stays silent.
A-10An authorised moderator's mute stops every audio role from every supported device, including existing subscriptions and attempts to republish under another audio role; video may continue. Unmuting does not force capture. Ordinary users cannot perform the action.
A-11Rights changes update the interface; an action using stale permissions is rejected by the server; settings changes use revision checks and expose inherited/effective media policy.
A-12A participant explicitly shares a window or display; viewers receive that source; source loss/permission revocation does not expose a different display. Voice remains responsive under presentation load.
A-13Multiple users edit a whiteboard and converge after reconnect; unauthorised edits, malformed operations, and stale membership are rejected; E2EE board state is opaque to the host.
A-14Camera publication is unavailable outside meeting policy; enabled meeting voice/camera remain within the approved sync/delay bounds, with defined degradation under congestion.
A-15Worker crashes before/after commit, effect dispatch and external success preserve every accepted event and its recoverable external work. Identical retries reconcile one effect; altered-payload reuse conflicts; expired-result/command handling cannot create another effect. Cursor expiry and duplicate federation delivery preserve those rules.
A-16Room creation uses accepted encryption defaults or the creator's explicit choice; every participant sees the recorded mode; unsupported encryption fails. In-place mode changes are rejected and later defaults do not change existing rooms.
A-17Approved latency, join, reconnect and revocation targets pass on the stated network/hardware fixture; measurements distinguish capture, playout, signalling, and propagation.
A-18Three human testers, then up to ten if available, share one voice room on one domain in test version 1 without screen sharing. Version 2 adds a second domain and runs A-02.
A-19Source and specification are published under the selected licences, deployment and recovery steps work, and independent implementations can run the conformance examples.
A-20One shared interface meets the supported KDE, GNOME, Windows, and macOS integration matrix; evidence identifies tested versions and remaining gaps.
A-21A recorded comparison evaluates existing protocol candidates against authoritative hosting, serverless transport, E2EE, media control, extensibility, and operational effort before selecting the foundation.
A-22Gaming, open-source project, and corporate-work walkthroughs exercise their agreed room/membership/policy needs without changing the core protocol. No unapproved enterprise feature is implied.
A-23Initial KDE Wayland and Windows clients support one-domain room voice and basic text for the test cohort; macOS remains tracked for a later release and the optional D-053 XWayland mouse-input adapter is identified separately from the native Wayland window.
A-24The desired first-version web client uses the approved browser PTT policy; tests include focus/tab loss while held, suspension, permission changes, and encryption/media compatibility. No unsupported global-hotkey claim is displayed.
A-25Every implementation specification has Configuration, Testing, and Acceptance criteria sections; configuration/defaults match the code, unit-test coverage is specified, and acceptance conditions are specific testable bullets. Draft gaps are explicit and are resolved before the affected implementation is declared complete.
A-26Separate client and server specifications identify their respective implementation responsibilities, configuration ownership, unit tests and acceptance criteria, linking shared protocol/security/media contracts without conflicting definitions.
A-27Public listing/self-join and private unlisted/invited admission follow the fixed bundles without bypassing federation, bans or capacity. Admit/remove/re-admit around distinct messages and retrieve only retained content from membership periods, excluding absences; first-time members receive nothing from before admission. Apply the same eligibility to every delivered retrieval feature and key flow.
A-28A persistent room member outside the live session obtains no live-media keys; leaving voice preserves text membership. Removal/device revocation excludes replacement-epoch keys and blocks obsolete-epoch publication by the defined cutoff; failed rekey pauses it. Measure the live-media transition under A-29 instead of claiming instantaneous exclusion at commit. Concurrent joins/removals and reconnect cannot reintroduce revoked recipients.
A-29Observe accepted/pending/effective/failed/superseded enforcement under partial adapter failure, post-commit timeout, stale callbacks and control partition. Deny new audio publication at the mute revision and stop established forwarding by the approved hard bound; admission-token expiry alone is not sufficient evidence.
A-30Back up, revoke a member/device, then restore the earlier snapshot. Reject stale credentials/membership and fence old authority/active media. If current authority cannot be recovered, keep affected scope closed. Record actual content loss and restore time against the approved objectives.
A-31A supported web client served by A joins B using the selected route/origin model. Test independent client origins, API/realtime connections, wrong audiences and disallowed origins; reusable home credentials are not disclosed to B.
A-32V1 requires an administrator-issued account invitation, tester-chosen password and one active device. Reject reused/expired/wrong-purpose invitations and a second active device under the selected flow. Recover login after key loss without decrypting old history; display the loss explicitly and preserve separate future-device trust checks.
A-33Sign the same account into KDE, Windows and web through approved independent device keys. Verify common account identity/roles/membership, independent sessions and text access; change a role or ban the account and reject stale actions on every client. Signing in does not move voice or overwrite local PTT/audio preferences.
A-34Link a device and recover on a clean installation after removing all approved test device stores. Compare readable message IDs/content to an eligible retained fixture with complete and incomplete backup coverage. Exclude pre-admission/absence intervals and expired/unbacked-up messages; report gaps. Inspect server storage/logs and verify that host-held secrets and password-only access cannot decrypt E2EE history.
A-35Reject pending/unapproved devices, wrong-account/domain approvals, substituted keys, replay, expired requests, revoked approvers and stale recovery generations. Revoke one device while retaining others; invalidate its sessions, pending work and future recipients without resurrecting authority from backup. Exercise concurrent approval/recovery/revocation and interrupted recovery-key rotation.
A-36Explicitly move voice from one approved client to another while holding PTT. Verify no overlapping live attendance/forwarding, a fresh destination press, account-wide mute and unchanged Cloudflare generation deadline. Race two moves and inject preparation/revocation failure, timeout, disconnect and stale retries; reconcile without automatic capture or a second voice owner. Other clients retain text access.
A-37On actual KDE Wayland and Windows fixtures, record/save a keyboard key, ProtoArc mouse button 4 and a joystick button from settings, then hold/release while another app/game has focus. Verify persistence, non-transmitting capture, cancel/failure, disconnect/reconnect, helper/permission loss and fresh-press recovery. Run focus/tab-loss cases on the supported browser matrix. All input classes are required; joystick hardware acceptance must pass before leaving testing under D-048.
A-38Server invitation and lobby access (R-070–R-072). In an isolated fixture, root shows sign-in before/after bootstrap; /setup works once and then returns 404. Register from raw keys and pasted full URLs, reject cross-origin/wrong-purpose input, and sign out/in on the original registered device. Grant access without admission/history, join by click, leave/rejoin with absence filtering, revoke access plus outstanding room keys, deny unauthorized role changes, and preserve legacy memberships and sessions across restart.
A-39D-055 room creation: test owner/moderator/member permissions, every text/voice/combined preset with both access/security choices, validation/quota boundaries, atomic creation/retry, initial grants without admission, explicit room join, independent text/voice navigation, cross-room crypto/history/moderation/lease isolation, and migration retaining lobby/account/session/key/history fixtures. Verify old clients receive only lobby data and unsupported schema rollback fails closed.
A-40D-056/D-057 identity/discovery: bare and same-domain qualified input select the existing account, foreign input never aliases locally, and DNS/URL changes preserve IDs/keys/permissions/history. Under P-028, exercise authenticated descriptor/profile/domain validation, DNS URI/SRV/dot/rewritten-target fixtures, browser-without-DNS support, credential non-disclosure on failure/change, and isolated root/path instances. Compare authoritative/recursive DNS with deployment configuration; report DNS-only completion separately from unimplemented clients/federation.
A-41R-079–R-082 conversations: first/second channel activation, idempotent current-call activation, same-account/date grouping and strict two-minute boundary, own-message contrast/forced colours, inline replies including reply-to-reply, failed draft retention, reload and unavailable originals. Run three browsers with two in one thread and one in the parent; verify only the paired listeners receive audio. Move two into a second thread and verify the first thread is isolated; move the remaining caller into the parent and verify neither thread hears it. Verify fresh PTT, inherited moderation/access, signed context, retained history and device-copy integrity under SPEC-013.
A-42D-102/D-103 login expiry: verify 30-day default, finite/Unlimited owner policies, strict signed claims and immutable registry binding, old deadlines through migration/policy edits, immediate logout/device/account/key revocation and restart. Exercise wrong/replayed password/device proofs, bounded prepare/activate/retirement and concurrent authority changes. In isolated browsers with live audio, retain voice ID and draft through early renewal, simulate secure-storage failure and lost activation response, reconcile another window and reload, then reject the old token after the overlap. Validate warning thresholds/server-clock anchoring and Unlimited silence; exercise issuance/renewal in real workerd separately.
A-43D-104: show saved servers as tree roots, Add server, correct named server/channel context actions, and keyboard/search traversal through eight channel levels. Reject a ninth atomically. Required parent access gates child metadata, membership, text/history/copies and voice; revocation closes intervals and restoration requires rejoin. Independent branches remain accessible with no hidden ancestor identity. Bottom-left Messages opens an unread summary without marking it read; incoming DM dots identify only the qualified sender, respect reduced motion and clear when read.
A-44D-105: exercise all server/channel/personal PTT combinations, legacy fail-closed behavior and schema-8 migration. With generated microphone audio through real browser/relay connections, verify explicit enabling, silence, sustained speech, quiet release, maximum duration, focus loss, moderator mute, authority failure and mandatory policy changes. Personal PTT remains available under optional policy. Physical microphone sensitivity and desktop hardware remain separate human acceptance.
A-45D-108: verify three separate bottom-left bars, active destination independent of viewed text/server, direct Leave and explicit Join/Move/Cancel, accessible expanded context/diagnostics, held PTT and voice activation with existing gates, persistent unexpected-disconnect reason/log/manual recovery, self picture and unread/settings controls. Check keyboard/pointer, narrow/short windows, 75–200% scale and light/dark/forced colours without horizontal overflow or unreachable actions.
A-46D-110: two simultaneously expanded server/account branches; qualified selection, keyboard hierarchy and context actions; no implicit admission or voice move. Verify automatic content fitting, manual drag/keyboard widths, per-device persistence and reset, long identities, narrow windows and UI scaling without hiding controls or changing saved widths. Background failure/replaced-session results cannot show stale authorized lists.
A-47D-115: public links round-trip through Add server; denied roots persist/retry/remove without channel requests; public targets admit for text, hidden targets disclose no metadata; existing accounts, credentials and voice remain isolated.
A-48D-118/D-120/D-126: group saved accounts under one verified server root with the qualified account in its subdued subtitle and no separate selector row; switch using account history and channel Join as; preserve account-scoped drafts, permissions and the prior context on failed sign-in/access. Dropdown changes immediately join text and switch an existing same-channel voice identity, while unrelated/already-matching calls remain intact. Verify fresh PTT, sign-in continuation/cancellation, reload, expired sessions, qualified namesakes, stale results and keyboard/scaled layouts.
A-49R-117–R-121/D-128–D-130: ordinary-channel and accepted direct/group screen sharing with one combined all-screen view or an explicit screen/window, both intent controls, role-checked relay limits/exceptions and safe mixed-route fallback. Verify actual video and optional presentation sound synchronized under SPEC-024, with microphone alignment measured separately, preserving responsive voice, microphone-only PTT and moderator all-audio mute. Two listeners independently configure default half-volume game-sound ducking during PTT/speech, without compounded attenuation or changed sender packets. Source loss, identity movement, revocation and incompatible clients cannot restart or disclose capture. Record actual KDE/Windows/browser capture evidence separately from automated fixtures.

Requirement coverage

R-117–R-121/D-128–D-130 add requested screen-sharing validation under A-49. SPEC-023 owns the D-134 selected profile and records platform/capacity validation gates; no screen-sharing test pass is claimed by alpha.23. A-12/A-17 expand to combined displays, optional sound, mixed routing and paired audiovisual timing when the feature is delivered.

RequirementsSpecificationAcceptance
R-117–R-121023 (shared contract), 005 (client), 008 (server), 004/016/017/018/022 (existing boundaries)A-49 plus applicable A-10/A-11/A-12/A-17/A-20/A-24/A-29
R-001, R-002, R-003, R-004000A-01
R-005001, 005, 006A-22
R-006, R-037002, 003A-02
R-007, R-035002, 006A-03
R-008000, 002, 006A-19
R-009, R-012001, 005A-04
R-010004A-12
R-011006A-13
R-013, R-014, R-015003, 004, 006A-05
R-016, R-017003A-06
R-018, R-019, R-020, R-021, R-038005A-07, A-20
R-022004, 005A-07
R-023, R-024004, 005A-08
R-025, R-026, R-028, R-029, R-043004, 005A-09, A-10
R-027002, 004A-10
R-030, R-034005, 008A-11
R-031, R-032004A-12, A-17
R-033004A-14
R-036, R-042003A-16
R-039002, research notesA-21
R-040, R-041007A-18 and the staged scenarios above
R-044, R-045, R-047001, 005, 007A-23
R-046, R-048005, 007A-24; first-version inclusion is a priority rather than a hard gate
R-049, R-050, R-051000 and every implementation specificationA-25
R-052005, 008A-26
R-053, R-054, R-060001, 003, 006, 008A-27, A-28
R-055001, 003, 008A-16
R-056004, 005, 008A-10, A-29
R-057, R-058, R-059001, 003, 005, 007, 008A-23, A-32
R-061, R-062000, 005A-19, A-25
R-063, R-064003, 005, 008A-33, A-35
R-065, R-066003, 005, 006, 008A-34, A-35
R-067003, 004, 005, 008A-36, A-10, A-29
R-068, R-069004, 005, 007A-37, A-07, A-24
R-070, R-071, R-072005, 006, 008, 009A-38
R-073001, 003, 004, 005, 006, 008, 009A-39
R-074, R-075, R-076002, 003, 005, 008, 009, 010A-40
R-079, R-080, R-081, R-082004, 005, 006, 008, 009, 012, 013A-41
R-106, R-107005, 019A-19, A-25; D-100 component acceptance and browser coverage in SPEC-005
R-108003, 005, 008, 009A-42
R-109, R-110001, 005, 008, 012, 015, 018A-43
R-111004, 005, 008, 012A-08, A-44
R-112001, 005A-45
R-113001, 005, 015A-46
R-114001, 005, 008, 015A-47
R-115001, 005, 015A-48

Configuration

SPEC-023 owns the D-134 approved screen-sharing rates and sync targets. Configured rates and selected thresholds are not achieved performance results. Resolve measurement fixtures, windows, startup/paused-frame treatment and pass conditions before testing a claimed implementation. Do not count an indefinitely paused video as a successful synchronization test.

This specification owns validation-fixture and reporting configuration, not application runtime defaults. The logical property names below are PROPOSED. The performance thresholds are starting points for discussion, not approved service guarantees or media-buffer settings. Test version 1 should measure them even before final thresholds are accepted. Unresolved settings must be supplied/approved before a result can qualify as a release-gate pass.

PropertyType and purposeDefault and status
test.stageSelected milestone identifierRequired — no default, PROPOSED; prevents comparing a partial milestone with full-product completion
test.domain_countPositive count1 for test version 1; 2 for test version 2 — CONFIRMED scope
test.room_countPositive count1 voice room for the initial human tests — CONFIRMED scope
test.participant_countsList of positive counts[3, 10] — PROPOSED fixture endpoints within the confirmed 3–10 target; report actual available human count, never fabricate a ten-person result
test.screen_sharingBoolean fixture controlfalse for early voice baseline — PROPOSED; initial screen sharing is not required
test.platform_matrixOS/desktop/browser versions and hardware recordsExact versions OPEN; initial KDE Wayland/Windows platforms CONFIRMED
test.endpoint_rtt_max_msBaseline endpoint-to-ingress milliseconds40 — PROPOSED
test.added_jitter_max_msImpairment milliseconds10 — PROPOSED
test.random_packet_loss_percentImpairment percentage1 — PROPOSED; clean-network case also required
test.target_percentilePercentile for proposed latency targets95 — PROPOSED; estimator and sample sufficiency OPEN
test.gaming_voice_max_msCapture-to-remote-playout threshold150 — PROPOSED
test.ptt_gate_max_msInput-event-to-open-gate threshold on an established path20 — PROPOSED; full first-syllable delivery is measured separately
test.meeting_voice_max_msCapture-to-remote-playout threshold250 — PROPOSED
test.webcam_absolute_skew_max_msAbsolute camera/voice playout skew80 — PROPOSED; asymmetric bounds may replace this after review
test.voice_join_max_msEstablished-client join, excluding human/OS prompts3000 — PROPOSED
test.moderator_mute_max_msAccepted moderation-to-forwarding-stop threshold1000 — PROPOSED percentile threshold; hard bound remains OPEN
test.moderator_mute_hard_max_msAccepted mute revision to cessation of every affected forwarding path, including failure/partition fixtureOPEN — positive hard maximum; must match the selected forwarding-lease/revocation contract, not the p95 target
test.message_acceptance_max_msLocal-domain send-to-durable-acceptance threshold500 — PROPOSED
test.run_duration_seconds, test.minimum_samples, test.clock_error_max_msRun length, sample count and measurement uncertaintyOPEN — not selected
test.fixture_seedReproducibility seed for deterministic fixturesRequired — no default, PROPOSED; record it in the result

Proposed baseline fixture: 3 and 10 participants, one room, no screen share, wired audio devices, each endpoint at no more than 40 ms RTT to the selected media ingress, up to 10 ms added jitter and 1% random packet loss, and sufficient uncongested bandwidth. Record actual media inter-region path and hardware; the endpoint RTT condition alone does not bound the SFU's internal path. Test clean and impaired networks separately, then add presentation congestion at its milestone.

Use recorded test signals and synchronized clocks or calibrated loopback methods for end-to-end delay; do not substitute ping for mouth-to-ear latency. Define sample counts, run lengths, percentiles, loss patterns, and resource budgets before treating these as release gates. Internet-wide guarantees are not implied.

The applicable fixture must record the admission/forwarding lease settings, initial policy revision, operation correlation IDs, packet/audio observation point and clock uncertainty. Define the percentile estimator, minimum sample count, run duration, correlated versus independent loss patterns and treatment of incomplete observations. Input-event-to-gate timing excludes OS event-delivery delay; report physical-input-to-remote-audio separately when measured. Relay forwarding stop is distinct from draining audio already buffered at a receiver. An absent completion event cannot be discarded to improve the percentile; report a failure or invalid measurement under the approved pass rule. Missing thresholds remain unresolved, never an automatic pass.

Selected V1 validation fixture (D-024/D-030)

The following resolves the V1 measurement choices only. Run clean and impaired fixtures separately with the actual 3–10 humans and declared hardware. Use 40 ms maximum endpoint-to-relay RTT, 10 ms added jitter and 1% independent random packet loss for the impaired fixture; record actual observed conditions. A developer integration test is not this human fixture.

Use nearest-rank p95 over at least 1000 valid observations during at least 300 seconds. Record invalid/missing observations as failures, not omitted fast samples. Clock uncertainty must be at most 5 ms for latency results; deployment clock skew must separately meet SPEC-003's 250 ms bound. Select p95 targets: capture-to-remote-playout 150 ms, input-event-to-gate 20 ms, voice join 3000 ms, normal moderator forwarding stop 1000 ms, and durable local message acceptance 500 ms. Every moderator revocation, including control partition, has a separate hard maximum of 4000 ms. Receiver buffered-audio drain is measured separately from relay forwarding.

D-062 adds deterministic rendered-audio jitter regression coverage under SPEC-004. The 150 ms target above still applies to its declared nearby-relay fixture; Canada/EU and Australian paths are reported separately. Bounded buffering is permitted for continuity, but neither ping nor a loss-free synthetic result establishes audible international-call quality.

Build verification records dependency locks, specification revision, unit/integration results, Workers build, native helper builds and produced client artefacts. A Windows cross-compile does not verify Windows PTT; a successful portal registration does not verify in-game release handling. Required real-platform and human results stay unverified until performed. No release or full V1 claim follows from passing automated checks alone.

Testing

SPEC-025's managed trial release requires provider adapter/ownership/renewal/replay/key/config units; actual local Chromium/Firefox authenticated RTP expiry and epoch recovery; uncompressed sound/mute tests; two-authority managed-move fencing; generated actual Cloudflare SFU delivery; and the complete application share/watch/sound/PTT/Stop flow without native video packets. Use the persisted ten-run envelope for provider experiments, retaining failed and partial outcomes and confirming cleanup. Final validation distinguishes local synthetic browser evidence from physical Windows/KDE, GPU and cross-network performance. D-159 authorizes validated rollout and requires the existing configured/observed/DO/assets checks.

A-49 units cover the SPEC-023 policy, media timing and listener ducking responsibilities. Integration distinguishes received packets from rendered content and tests high-bitrate direct-to-relay fallback, paired audiovisual output, all-screen composition and two listeners with different ducking preferences. Physical KDE/Windows and each claimed browser capture/sound mode require separate acceptance evidence.

Specification checks for D-044–D-048 must preserve current V1 versus proposed-successor scope, resolve local links/IDs, trace R-063–R-069 to A-33–A-37 and keep configuration ownership in SPEC-003/005/006. These document checks establish neither feature implementation nor physical hardware support.

D-041 adds Brisbane, Australia tester paths to hosted validation. Record actual city/region, ISP/access type, selected TURN path and relay location; compare Canada–Brisbane and Brisbane–Brisbane pairs when the cohort permits. Measure capture-to-playout, join time, jitter/loss and moderation separately using the selected V1 methods. Report cross-region results separately from the baseline fixture, including failed targets. A local automated probe or endpoint ping does not establish Australian voice performance. D-042 permits one relay path for testing while requiring regional flexibility in the eventual service; do not extrapolate a V1 result to global service performance.

Resource-sampling reporting tests accumulate observed scheduling-counter changes by stable process/thread start identity and retain contributions after retirement. First observations of preexisting tasks establish a baseline; tasks born after measurement begins include their first observed counters. Units cover retirement, multiple generations, PID/TID reuse, observation gaps and root/child exit, plus a generated-thread CLI check. Reports state that unobserved sub-interval tasks and activity after a retired task’s final sample remain unavailable; observed scheduling counters are not exact hardware wakeups. This defines measurement accounting without adding an application performance threshold.

Application unit-test responsibilities are specified in SPEC-001 through SPEC-006 and SPEC-008. Any validation/reporting code introduced for this specification must itself have unit coverage for:

  • Fixture configuration parsing, explicit defaults, required fields, unsupported stage/platform combinations, invalid units/counts, and unresolved settings that cannot produce a release-gate pass.
  • Unit conversion and duration/percentile calculations using fixed sample sets, including the chosen estimator, empty/insufficient samples, missing measurements, and clock-error bounds.
  • Threshold comparisons at below/exactly/above each limit; percentile targets and hard maximums are not interchangeable.
  • Event pairing for capture/playout, join, moderation acceptance/enforcement, and message send/commit; mismatched IDs or absent end events produce an invalid/incomplete result rather than an invented latency.
  • Requirement/scenario mapping, valid specification revisions, and stage accounting; a skipped/unimplemented/deferred scenario never becomes passed or full-product complete.
  • Report redaction and deterministic fixture replay from the recorded seed/configuration; actual participant count cannot be replaced with the target count.
  • Milestone applicability, desired-but-absent versus delivered-but-failing features, single-device versus future multi-device cases, and exact coverage of every scenario at its applicable stage.
  • Enforcement-state correlation including incomplete/superseded operations, lease/hard-bound comparisons and distinction between relay stop and endpoint playout; no missing completion is silently excluded from a pass.

The first alpha includes protocol/service, native relay, local Workers and three-context browser checks under tests/ and native/internal/relay. The clean/impaired human performance harness remains unimplemented. The unit-test plan above does not replace human listening/PTT testing, real platform runs, two-domain integration, media-provider validation, security review, or performance measurement.

Acceptance criteria

  • A delivered screen-sharing increment passes the selected SPEC-023/A-49 profile with resolved configuration, measured relay enforcement and audiovisual output, and explicit platform gaps; alpha.23 or a specification-only draft is not represented as satisfying that increment.
  • A-47 / R-114: public links round-trip through Add server, preserve denied roots without channel disclosure, open only permitted text, and leave voice unchanged.
  • Delivered linked-device/recovery/voice-move features pass A-33–A-36 under an approved successor protocol and migration; passing legacy A-32 alone cannot establish their completion.
  • PTT expansion passes A-37, including the user's physical ProtoArc button 4 and a real joystick on KDE/Windows. D-048's joystick test remains an exit gate even when hardware is unavailable during initial work.
  • Hosted cohort evidence includes an Australian endpoint under D-041, records its actual location/network and selected relay path, and reports measured voice/join latency against the existing targets without substituting a local test or changing hosting priority.
  • Each numbered specification passes A-25: its configuration/default inventory, concrete unit-test plan, and acceptance bullet list exist and are internally consistent; relevant OPEN values have been resolved before its implementation is accepted.
  • Client and server ownership passes A-26: each has a separate specification, backend permission/default ownership is unambiguous, and shared contracts resolve to the same canonical definitions.
  • For the declared milestone, every applicable requirement maps to a recorded scenario and result with specification revision, implementation revision, fixture configuration, and observed outcome. Missing/skipped results remain visibly incomplete.
  • Test version 1 records the actual 3–10-person cohort using one voice room with basic text on one domain, including KDE Wayland/Windows PTT and moderation results; no screen-sharing result is required for that milestone. See A-18/A-23.
  • Test version 2 records independent domain identities/configuration and successful cross-domain room participation in both host directions, plus rejected privilege claims and the approved outage/refusal cases. See A-02.
  • Any delivered web client passes focus-loss/tab-switch/permission-revocation tests on the declared browser matrix; if the desired first-version web client is absent, the release report explicitly records that gap. See A-24.
  • Performance reports use the approved thresholds, estimator, sample sufficiency and clock-error limits, include clean/impaired fixtures, and separately report invalid measurements; no p95 result is represented as a hard maximum guarantee. See A-17.
  • Full-spec completion is claimed only after later required platforms, media features, whiteboards, encryption, publication and independent-operation scenarios are verified; completion of one early milestone is labelled only as that milestone.
  • Every scenario has an explicit stage disposition and delivered scope; a V1 result does not claim multiple-device or public-room coverage that was not run. Delivered optional features meet their applicable correctness/security cases even when delivery itself was Desired.
  • The V1 report identifies the private E2EE room, unformatted messages/reconnect, invitation/password flow, single-active-device enforcement and explicit key-loss limitation. See A-23/A-32.

Readiness gaps

Historical draft prerequisites, resolved for V1 by D-024–D-031 and SPEC-009: choose the protocol/profile and browser route; detail the confirmed invitation/password flow, password verification/reset/MFA policy and device replacement; choose E2EE suite and device trust; pin tester OS/browser matrix and toolkit; select a media adapter with active-lease/hard-mute proof; resolve V1 configuration defaults, permission precedence, wire schemas, epoch transitions, idempotency/commit rules and error/limit rules. V1 room type, encryption, text scope, device count and key-loss outcome are already selected in D-020–D-022; do not reopen those as unanswered choices.

Before a broader release: verify the selected SPEC-011 recovery/retention profile on real platforms; complete the supported deployment matrix, capacity/cost limits, broader upgrade policy and privacy/security review. D-035 selects source/specification licensing; publication and independent-operation evidence under A-19 remain separate gates. Record implementation status per requirement as not started, partial, implemented, or verified. The first alpha implementation and actual evidence are recorded in the build report. Unverified human/platform and later-feature obligations remain incomplete.