Rust and Tooling
The Rust workspace vocabulary and the checks that gate a change.
Applies-To
A field in the master specification's document-control block naming the released
software version the document describes. It tracks the workspace package version
and is bound to it by cargo xtask spec, so the specification and the shipped
artifact cannot silently drift.
Why it matters here
The specification is the architecture of record agents are told to trust. When it described v0.2.0 as the first functional release while v0.4.0 had shipped, every decision built on it inherited a false baseline. Applies-To is the anchor the lock-step check binds, making constitution principle P-11 mechanical rather than remembered.
See also: spec-impact, xtask
MSRV
Also known as: minimum supported Rust version
The oldest toolchain release a crate compiles with, declared as
rust-version in its manifest.
Distinct from the toolchain a project builds with. The first is a compatibility promise to consumers; the second is a reproducibility control for the project.
Why it matters here
fragcap declares 1.88 while pinning its build toolchain at 1.96.0. A declared minimum that is never exercised is an unverified claim, so a dedicated check builds the complete workspace at the minimum. S102 makes that check cover the exact native proxy protocol graph as well as existing crates.
See also: xtask
spec-impact
A field on each changelog.d/ changelog fragment, written as a leading
<!-- spec-impact: ... --> comment, whose value is either none or a list of
specification section numbers the change modified. The release gate reads it to
refuse a release whose fragment claims a specification change the release diff
does not contain.
Why it matters here
It closes the reverse of specification drift: a change that claims it touched a section without the section actually changing. The value is machine readable and stripped before the changelog is assembled, so the claim is checked without cluttering the published changelog.
See also: Applies-To, xtask
Test tier
One of the four levels specification section 25.2 defines, distinguished by what each needs in order to run.
| Tier | Needs | In continuous integration |
|---|---|---|
| 0, unit | nothing | yes |
| 1, pipeline | nothing | yes |
| 2, platform | privilege and a capture driver | yes, on a Windows runner |
| 3, live compatibility | an already published release, privilege, a driver, and a game | no, optional operator-owned manual work |
Why it matters here
Tier 1 is the one the architecture was shaped to make possible. Because a replay source and a scripted attributor substitute for the two platform-dependent seams, the whole pipeline is testable on any machine with no privilege. That is the return on keeping capture and attribution apart.
Tier 3 is compatibility evidence for exact already published product bytes. It is never an automated implementation gate, an agent does not run it, and its absence does not imply compatibility or block controlled implementation acceptance.
See also: Fixture corpus, Replay source
Write amplification
Extra underlying writer calls caused by dividing identical output into small batches. In fragcap's application-writer measurements this means call count, not flash-storage wear or extra observed records.
Rust's BufWriter accumulates small writes in a byte buffer before issuing larger writes to the underlying destination. Its default capacity can change; with_capacity chooses an explicit capacity. Buffered records are not successfully written merely because they entered memory: explicit flush errors must still be checked and reconciled.
Why it matters here
Metadata-heavy QUIC/UDP evidence can produce thousands of distinct observations, so S150 reduces physical write calls without merging observations, expanding the event queue, coupling forwarding to storage, or changing loss accounting. A write-count regression establishes this efficiency change, not the exact cause of a historical Windows scheduling or storage stall.
See also: Bounded buffer, Backpressure
References:
xtask
A Cargo convention in which repository-wide tasks are implemented as a workspace member invoked through a cargo alias, requiring nothing installed beyond the language toolchain.
Why it matters here
fragcap's conventions and dependency-direction checks live here rather than in shell scripts, because a check written in the project's own language can be unit tested against known-bad input. A linter whose matcher never fires is indistinguishable from a clean repository.