Claude/hopeful ride u0k49i - #1
Merged
Merged
Conversation
…and CI - docs/CLEAN-TEAM.md: the standing prompt for clean-room sessions (brief, milestones M0-M4, execution-environment network policy) as part of the provenance record. - deny.toml: cargo-deny bans for every published implementation of this protocol (ableton-link-rs, ableton-link, rusty_link, abl_link), a no-copyleft license allowlist, and registry-only sources. - .github/workflows/ci.yml: fmt/clippy/test against the pinned spec release vectors, plus cargo-deny as a separate gate. I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
M0: workspace with two crates. Proposed (unpublished, unclaimed on crates.io) names: 'tactus-wire' for the pure codec, 'tactus' for the runtime peer — tactus being the early-music term for the shared beat; no Link branding. Publication awaits explicit confirmation. M1: common serialization rules from spec chapter 00 (big-endian primitives, length-prefixed strings/vectors, tagged payload container with skip/exact-size/forward-compat rules) and encode/decode for every message in chapters 01-03: discovery Alive/Response/ByeBye with the peer-state payload, sync Ping/Pong with verbatim-echo semantics, and LinkAudio PeerAnnouncement/ChannelByes/Pong/ChannelRequest/ StopChannelRequest/AudioBuffer (bare structure, chunk records, PCM i16). Acceptance: tests/vectors.rs decodes all 4,346 datagrams in the five released captures and re-encodes each byte-for-byte, plus unit tests pinning the documented message shapes (107/121-byte peer state, 25/41/ 57/73-byte sync shapes, 576-byte single-chunk audio datagram). I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
Runtime peer (crates/tactus) over the M1 codec: - Gateways (chapter 01 par2): per-interface multicast-receive socket (wildcard:20808, address reuse, group joined per interface) and a unicast socket for all sending; multicast loopback only on loopback gateways. IPv4; loopback gateway by default, others via Config. - Discovery (chapter 01): 250 ms Alives with immediate state-change broadcasts at 50 ms minimum spacing, unicast Response before payload processing, ByeBye on disable, peer table with ttl expiry and the earliest-deadline+1s prune timer. - Measurement (chapter 02 par4-5): stateless verbatim-echo responder; initiator chains pings off pongs, 50 ms retry x5, both midpoint offset estimators, median filter over >100 samples. - Session election (chapter 02 par7): ghost-time seniority join rule with 500 ms epsilon and byte-wise id tie-break, founder-preferred measurement targets, 30 s re-measurement of joined sessions, cached measured sessions, and the found-fresh-session reset (new NodeId, seamless tempo/beat) when the last session peer disappears. - Timeline (chapter 02 par6): beat-origin priority adoption with tempo re-clamping; modification rule max(beats-at-now, origin+1). - Start/stop (chapter 02 par8): ghost-timestamp ordering, relay even when sync is disabled locally, surfaced only when enabled. - Beat grid (chapter 02 par9): integer microbeat phase/alignUp/alignNear, app-beat encoding and the composing inverse, all under unit tests including the quantum-independence of session beat time. Acceptance (tests/loopback.rs, self-interop on loopback multicast): mutual discovery, single-session election with the older session winning, tempo convergence both directions, beat-phase alignment at quantum 4, transport start/stop propagation, ByeBye-triggered session reset with a fresh NodeId, and ttl expiry of a silently dead peer. I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
…ment LinkAudio runtime (chapter 03) on top of the M2 peer: - Endpoint advertisement (par2): aep4 piggybacked on discovery while audio is enabled; absence clears the remote record. - Control plane (par4): unicast PeerAnnouncements every 250 ms to all session-peer audio endpoints with payload-budget splitting and the first-message-only __ht ping; Pong echo and the 10-sample RTT window with the speed/(1+jitter) path-quality model; ChannelRequest with 5 s keepalive re-send and ttl-based requester expiry (+1 s padding); StopChannelRequest immediate removal; ChannelByes on unpublish and messenger shutdown. - Data plane (par5): sender chunking with contiguity merging, the 502-sample-byte datagram cap, sequence numbers from 1, big-endian frame-interleaved PCM i16; receiver dispatch to sources with cross-session buffers dropped. - Beat alignment (par6): wire beats = app beat - session offset on the sink; + receiver offset on the source; quantum-independent session beat time verified in unit tests. - Subscriber channel knowledge (par7.3): per (channel, gateway) entries, announcement-refreshed, removed by bye/timeout/peer departure, with source-endpoint admission of announcements. Acceptance (tests/audio_loopback.rs, self-interop): announce/subscribe/ stream/unsubscribe/withdraw lifecycle, sample integrity across the wire, received chunk beats equal to the send cursor within 0.001 beat, increasing sequence numbers, and request expiry silencing the sink when a subscriber dies silently. I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
- crates/tactus/src/bin/conformance-peer.rs: implements the spec repo's CANDIDATE-CONTRACT.md — starts disabled at 120 bpm / quantum 4, the enable/disable/tempo/start/stop/startstop-sync/quit commands, the audio feature (audio-enable publishes one channel and pumps a continuous sine; audio-subscribe by index of the sorted visible list), and status lines on change with a sub-500 ms heartbeat. - tests/conformance_contract.rs: a miniature harness that drives two conformance-peer processes through the same scenarios run.py runs (discovery-join-leave, tempo-follow, start-stop, audio-stream) and asserts the contract surface end to end, including quit-within-5s. - .github/workflows/conformance.yml: adapted from the spec repo's example workflow; fetches the spec + harness at the pinned release into the runner's temp directory (CI cache, never the tree) and runs reference-vs-candidate scenarios on loopback with the audio feature. The harness's reference cache stays outside this repository and its output is consumed as observations only, per PROVENANCE.md. I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
Name proposal accepted (M0 gate). Both crates verified packageable via cargo package --workspace; publication itself happens once a crates.io token is available. I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
…n README The workflows pinned the spec by a full SHA whose tail was wrong (only the abbreviated da7a38c had been verified), so actions/checkout failed with 'not our ref' on every CI run. Pin the verified SHA da7a38c543c52433a5476f415c36c5de2008d32f (v0.4.0 content). README gains a 'Testing and conformance' section: the three test layers, how vectors are located (LINK_WIRE_SPEC_DIR / sibling checkout / REQUIRE_VECTORS), how to run the spec repo's harness locally against conformance-peer, and the PROVENANCE firewall rules that apply to that run. I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
- set -o pipefail in the harness step: run.py's exit code was masked by the tee pipe, so the job reported success while a tempo-follow observation FAILed inside it (run 27370332248). - Pin SPEC_REF to the spec branch commit carrying the harness fixes (closed-loop hut tempo driving, completable scenario deltas); fetch the pin by SHA via git init+fetch so non-default-branch commits work. - Same pin in ci.yml for consistency (vectors unchanged). I have complied with PROVENANCE.md; this contribution is derived only from permitted inputs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.