- First run (and when CONSENT_VERSION changes): a question over the launcher
with four switches, all off, what each sends in plain words, what is never
sent, "View what would be sent" (the exact JSON), and "Send nothing" /
"Save choices".
- Settings → Data collection: the same switches any time, the install ID and
what waits, "View what would be sent" and "Delete my data" (server deletion,
outbox cleared, new install ID).
- The outbox is sent at start and on close (at most 3 s), only when there is a
server (none yet) and only what the player allows.
- CLI `horizon-launcher data status|allow|deny|show|delete|send|bug|benchmark`
and MCP tools data_collection, set_data_collection, data_preview,
delete_my_data, report_bug. Bug reports and benchmark uploads are printed for
the player to confirm; logs are scrubbed and lose chat lines.
- horizon-telemetry joins the launcher's paths (launcher.yml, release_train,
pr_ready).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
pr_ready is the one self-check to run before asking for review: from the
files a branch changes it runs rustfmt, clippy with warnings denied, the
tests of the touched crates (mapped through cargo metadata), the launcher's
own workspace when it is affected, the tokens.css check, the Cargo.lock
rule, the Python tests and the public-tree check, and the vanilla harnesses
the change can affect, picked by tools/parity.py exactly as CI's parity job
picks them. It runs locally or on a fleet machine through ~/fleet/rbuild;
on the Mac mini the harnesses use the parity runner's own workspace and
scripts. It prints one Markdown block for the pull request body and exits
non-zero on any failure.
tools/parity.py gains --changed-files for copies without Git history, and
tools/ci/vanilla-data.sh accepts the preparation key from outside.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ludovic Marie