The throughput window and the byte count disagreed. Bytes were counted from
the moment the upload threads started, the 1.5 s queue-fill ramp included;
the divisor was that same span with 1.5 s subtracted from it. So a numerator
covering ~8.3 s was divided by ~6.8 s, and every up= figure nesdoctor has
ever published is high by ~22%.
Snapshot the counter and the clock together after the ramp, and measure both
from there. Excluding the ramp is also the better measurement: TCP slow-start
lives in it, so it is not the steady state a session gets.
Found by running speedtest on the same line in the same afternoon — 284 Mbps
against our 502 — which is the only way it could have been found. The code
was self-consistent and the number it printed was plausible, so no amount of
re-reading would have shown it. A boundary effect remains and is documented
in the code rather than papered over: bytes arrive one completed 8 MiB POST
at a time, so up= keeps a few per cent of upward slack.
Submissions collected to date stay useful as a floor and as a bufferbloat
corpus. They are not usable as throughput.
Reported from a real machine on release day. The README asks strangers to run a
binary, so it should say what actually happens when they try.
The why matters more than the workaround: SmartScreen objects to the file being
unsigned and having no download history, not to anything the program does. And
history attaches to the file hash, so a project releasing four times in an
afternoon never accumulates any -- waiting is not a strategy.
Offers the source build as the version that requires no trust, and says that
stopping is a reasonable choice. Reproducible CI builds and published checksums
prove provenance without moving SmartScreen an inch, and pretending otherwise
would be the kind of overclaim this tool cannot afford.
The fallback worked -- the macOS runner now reports a GPU instead of
`unknown`, and the raw probe dump settled which of the two candidate causes it
was: a headless virtual Mac with no display adapter to enumerate, so
`system_profiler` had nothing and the parser was never at fault.
It read `Apple M1 (Virtual) (integrated)`, because the SoC name already
carries a parenthetical on a VM. Em-dash instead. The suffix stays: it records
that the name came from the chip rather than from a display adapter, which is
the difference between a machine with no GPU and a machine with no display.
The macOS arm added in the previous commit did not change anything -- the
runner still reported `gpu=unknown`. Checked rather than assumed, which is the
only reason it is known.
Two possible causes and no way to choose between them from here: either the
`system_profiler SPDisplaysDataType` parsing is wrong, or that machine is a
headless virtual Mac with no display adapter to enumerate at all, in which case
`unknown` was the correct answer and there is nothing to fix. The second is
likely and the first is not ruled out.
So, rather than guessing again: on an arm64 Mac the GPU *is* the SoC, so the
chip name is a true and useful answer even with no display attached.
`sysctl -n machdep.cpu.brand_string` works headless and yields
"Apple M1 (integrated)". Intel Macs get no fallback, because there the GPU may
be integrated or discrete and a guess would be wrong rather than coarse.
And the CI step now dumps the **raw** output of each platform's probes --
`system_profiler`, `Get-CimInstance Win32_VideoController`, `Get-PSDrive`,
`df -Pk`, `/sys/class/drm` -- into its own log group. A field that comes back
empty can then be told apart from a parser that is wrong, which is exactly the
distinction that cost this round trip. All of it is `|| true`: the step exists
for looking, and a probe that misbehaves on a runner must never fail a release.
Seen in the macOS CI log:
nesdoctor 0.2.2 | macos/aarch64 | gpu=unknown | ...
`gpus()` had a Linux arm, a Windows arm, and `Vec::new()` for everything else.
Macs are clients rather than hosts, so it went unnoticed -- but 0041 wants a
client vendor matrix and an unlabelled row is no use in one. An M-series
integrated GPU and a discrete Radeon in an Intel Mac decode very differently,
and "unknown" cannot tell them apart.
`system_profiler SPDisplaysDataType` is the only place the chipset name lives.
Parsed loosely: the format has changed between macOS releases, so a name we
cannot find costs a field rather than the run. Vendor is matched over Apple,
AMD, Radeon, NVIDIA and Intel; `render_node` stays `None` because macOS has
none and a Mac cannot host regardless.
Still missing on macOS and stated rather than papered over: filesystem types
and the display probe. The EDID path is sysfs on Linux and WMI on Windows, and
macOS exposes neither -- so Mac respondents report no colour depth or HDR
capability. That is a real gap for the video work, since Mac panels are exactly
the P3 and high-refresh cases worth knowing about, and it needs
`CoreDisplay`/`system_profiler` parsing rather than a one-line fix.
Three more things the macOS CI log showed, none of which had ever been visible
from this laptop.
`df -P` fixes the column order but not that the filesystem name is one word.
macOS emits
map auto_home 0 0 0 100% /System/Volumes/Data/home
which shifts every field by one, so indexing from the left read the capacity
percentage as part of the mount point and a device name as the size. The row
appeared in the log as `100% /System/Volumes/Data/home`, which is what gave it
away. Columns are now counted from the right, where `df` actually guarantees
them: size, used, avail, capacity, mount. A test covers the plain row, the
two-word `map auto_home` row, and an SMB share whose device name contains a
space -- the case that makes left-indexing wrong in principle rather than just
on Macs.
The `/System` filter I claimed to have added in the previous commit was not in
the file. The assertion that was supposed to catch that passed against the
wrong block, so it went in silently and `/System/Volumes/xarts` kept appearing
in the very output I had just quoted as fixed. It is there now, along with
`/private/var/vm` and `/Volumes/Recovery`, and verified by grep rather than by
belief.
And a filesystem reporting no capacity is not storage: `map auto_home`, devfs
and macOS signed asset bundles all report zero and were padding the filesystem
count in the summary line.
Net effect on the runner, across this commit and the last: 11 filesystems and
"483 GiB free of 1600 GiB" on a 320 GiB machine, down to the one real volume.
Found by reading what the macOS CI runner prints, which is the whole reason
that step was added an hour ago. First time anyone had looked at what these
probes return on a platform that is not this laptop:
/ 96 GiB free of 320 GiB
/System/Volumes/VM 96 GiB free of 320 GiB
/System/Volumes/Preboot 96 GiB free of 320 GiB
/System/Volumes/Update 96 GiB free of 320 GiB
/System/Volumes/Data 96 GiB free of 320 GiB
11 filesystems · 483 GiB free of 1600 GiB total
On a machine with 320 GiB. An APFS container presents each volume as its own
filesystem with its own `/dev/diskNsM`, so the device-name dedupe -- which
correctly collapses btrfs subvolumes -- cannot see that the space is shared.
Two changes.
`/System/Volumes` and `/private/var/vm` are skipped: they are not user storage,
and on a Mac they are most of the rows.
And filesystems are deduped by *pool* as well as by device. Two filesystems
reporting byte-identical capacity and byte-identical free space are one store,
whatever their device names say -- which also covers bind mounts and
thin-provisioned LVM, neither of which the device check catches either. Two
genuinely separate disks agreeing to the byte on both figures would cost one
row; a storage total inflated fivefold is a number a capacity plan gets built
on.
Simulated against the exact runner output: eight rows and 2560 GiB become one
row and 320 GiB.
The Windows runner, by contrast, was correct first time -- `C:` and `D:` are
genuinely separate and totalled 179 GiB free of 299 GiB. Worth recording that
the reason we know is that we looked, rather than that we reasoned about it.
CLAUDE.md said "Rust components are guest-side: they run inside a virtual
machine". That was true of every one of them until yesterday and is now false,
which makes it worse than a gap -- it is instruction that would send someone
looking for nesdoctor in the wrong half of the system.
Records the two things about it that hold nowhere else in this tree. Its
dependency list is part of its interface, because it is handed to strangers and
asked to be trusted. And it cannot be verified on the development machine
alone: both bugs it has shipped were Windows-only, found by users, in code
paths Linux never executes -- so prefer a property test that runs everywhere
over a platform check that runs nowhere, and read what the Windows and macOS
runners print.
A submission from a team machine with four drives and 22 TiB reported
`disk=8880`, and the field was not wrong so much as meaningless: it was the
free space on the single largest mount, with no capacity anywhere and no total.
A content store is sized against capacity.
Storage now reports four things, because they answer different questions and
one number could not:
diskfree total free across every real filesystem
disksize total capacity
diskmax the largest single filesystem, which is the real ceiling for any
one store -- a dataset cannot be spread across drives
disks how many there are
The ambiguous `disk` key is gone rather than silently redefined, so old rows
stay readable as what they were. `Get-PSDrive` reports Free *and* Used and we
were reading only Free, hence no capacity on Windows at all.
Pseudo-filesystems are now excluded by *type* rather than by mount path. Path
filtering missed `/tmp` on a tmpfs, whose free space is RAM -- so 7 GiB of
memory was being added to a storage total, which is exactly the sort of number
a capacity plan gets built on.
## The real finding, which was not about disks
"We are working blind on Windows" is correct, and both Windows bugs this tool
has had prove it: a virtual display adapter reported as the GPU, and a URL
truncated at its first `&`. Both were in code that only runs on Windows, both
were found by a person reading the results channel, and neither could have been
found here -- the development machine is Linux and `xdg-open` never sees a
shell.
Two things about that, and the first is the one that generalises.
`OPENERS` is now a const with a test asserting the property that actually
matters: **never hand a URL to anything that will re-parse it.** No `cmd`, no
`sh`, no `powershell`, no `start` builtin, and no argument that looks like it
wants the URL interpolated into it. Unlike the bug, that is checkable on every
platform in a millisecond. Verified by reintroducing `cmd /C start "" <url>`
and confirming the test fails with the right message, then reverting.
And CI already runs a real Windows machine and a real macOS one -- we simply
were not looking at them. Each smoke-tested target now prints its full report
and JSON into a collapsed log group. Deliberately not `set -e`: this step is
for looking, and a probe that misbehaves on a runner must not fail a release.
It turns "working blind" into "looking at it once per release", which would
have shown the Parsec adapter problem the first time a Windows binary was ever
built.
Version to 0.2.2.
Two submissions arrived carrying `v=0.2.0` and nothing else. Flagged from the
channel, not caught by us.
The Windows arm of `open_in_browser` was `cmd /C start "" <url>`. `cmd.exe`
re-parses its own command line and treats `&` as a command separator; Rust's
`Command` quotes arguments for the MSVC C runtime convention, which `cmd` does
not honour. So the URL was cut at its first `&` -- which in ours falls
immediately after `v=` -- and the browser opened
https://doctor.nestri.io/?v=0.2.0
carrying nothing whatsoever. Reproduced exactly with the same mechanism in a
POSIX shell: `sh -c 'echo <url>'` unquoted prints precisely that prefix.
Every Windows user who pressed Enter lost their entire report, and lost it
silently -- the page returned 200 and thanked them. Windows is most of this
audience, so most of the data we would ever have collected was going to
disappear this way.
Now `rundll32 url.dll,FileProtocolHandler`, which hands the URL to the shell's
protocol handler with no command interpreter anywhere in the path, so nothing
re-parses it. `explorer.exe` also opens URLs and was rejected: it returns a
non-zero exit status even on success, which would make the caller believe it
had failed and fall through.
The relay now also refuses to thank anyone for a version-only arrival, since an
older binary keeps producing them and a URL pasted into a shell unquoted does
the same thing.
Version to 0.2.1.
The README opens by saying the repository is mid-rewrite, nothing is stable,
and the documentation is behind the code -- all true, and it leaves a visitor
with nothing to do. There is now one thing here that is finished and runs on
its own machine, so it goes immediately after that note rather than buried in a
component table.
The section leads with the two install commands and the number worth having:
added latency under load, which decides whether a stream feels right and which
almost nobody has ever seen for their own connection. Then the display probe,
because "it tells you what your monitor can actually accept" is a better hook
for this audience than anything else in the file.
It also says plainly that this does not stream a game and that most machines
come back CLIENT, "a real answer, not a failure". A README that oversells the
one runnable thing would undo the reason it is worth running.
Three smaller corrections that follow:
`nesdoctor` gets its own heading rather than a row under the guest components.
It is neither control plane nor guest -- it runs on the reader's own machine,
which is the whole point of it.
Getting started said the Rust components "are not much use on their own yet".
That was true of every one of them yesterday and is now wrong; scoped to the
guest half, with `cargo run --release -p nesdoctor` called out as the exception.
And Contributing now asks for the thing we actually need. "Tell us where the
documentation failed you" was the most useful contribution when nothing could
be run; running nesdoctor and sending the result is worth more, because we have
almost no idea what the machines on the other end look like.
Checked: every relative link in the file resolves, and the scripts
doctor.nestri.io serves are byte-identical to the files the README points at --
which is the claim the section makes about them.
Two things, both of which every response collected without them is a response
we cannot go back for -- since a submission carries nothing that identifies
anyone, there is no second chance to ask.
## The display and decode probe
This is the readable half of the client capability probe our build order
already specifies -- GPU, decoder, display -- and its stated purpose is
attribution: told only that a stream "looks bad", the cheapest available
explanation is that our reconstruction ratio was too aggressive, so without
this we would lower the ratio and pay density for somebody else's window
manager.
presentation path x11 · bspwm
eDP-1 1920x1200 @ 60 Hz, 8-bit
Vulkan decode h264, h265
VA-API decode h264, h265, vp9
Session type, compositor, and whether we are under XWayland -- which is exactly
the objection raised against our own A/B rounds, now recorded automatically
rather than argued about. A bare window manager sets none of the XDG variables,
so bspwm and thirteen others are matched from the process list; a report that
cannot name bspwm cannot answer the challenge that named it.
From EDID, parsed here rather than shelled out to: native mode, refresh,
colour bit depth, which HDR transfer functions the panel accepts, BT.2020
colorimetry, and 4:2:0 chroma. The CTA-861 extension blocks are where all the
colour capability lives -- base EDID says nothing about any of it.
That decides real choices. Whether 10-bit is worth sending, whether BT.2020 is
worth encoding, which codec to reach for. Every one of those has so far been
decided against the one panel in this room -- which this now reports as 8-bit,
meaning the 10-bit work cannot be validated on it at all.
EDID is untrusted binary from a device node. Every read is bounds-checked and
every field optional: monitors ship broken EDIDs and docks synthesise worse
ones, so a bad panel costs one field rather than the run. Three tests, one of
which truncates the block mid-extension and asserts that no colour capability
is invented. The colorimetry byte offset was wrong the first time and the test
caught it, which is the argument for the test.
Present mode, tearing and fractional scaling need a real window and swapchain,
so they are absent and said to be absent rather than guessed.
## Early access
An optional email, asked last, after the verdict has printed -- so nobody types
an address before seeing what this said about their machine. Blank skips it.
The offer branches on the verdict, because telling someone with no KVM and a
grade-F uplink that we liked what their machine can do is a lie, and this
program's only real asset is that it does not flatter anyone. A host-capable
machine gets the host offer; everyone else gets early access as a player, which
is a true offer too.
It is the one identifying thing collected here, so: it appears in the
pre-submit disclosure with everything else, and the promise elsewhere had to be
reworded -- "no username, no identifiers" stopped being true the moment this
field existed, and leaving the old line standing would have been the dishonest
option. Validation is deliberately loose; arguing with somebody about their own
address over a regex loses the response outright.
Version to 0.2.0.
Our first respondent answered `otherlinux=yes` -- they have a Linux machine --
and their Windows desktop came back CLIENT, which is a dead end. The Linux box
is the result we have none of.
There is no way to ask them. A submission carries no hostname, no address and
no name, by design, so the moment the program exits whoever ran it is anonymous
and unreachable. That is the correct trade and it is not being changed. What
was wrong is that the program knew about the other machine *while they were
still reading* and said nothing.
So when someone answers that they have, or could set up, a Linux machine and
this one cannot host, the run now ends by asking for it -- with the command,
and with the reason stated plainly: nearly every result is a client, a host has
to be Linux with KVM, and one run over there is worth more than a hundred of
these. Including why we cannot follow up, since that is the honest argument for
doing it now.
The nudge is suppressed when the machine already qualifies as a host, because
then it is noise.
Our first response, and the GPU field is wrong:
gpu=Parsec%20Virtual%20Display%20Adapter&gpus=2
Parsec installs an indirect display driver, it enumerated first out of
`Win32_VideoController`, and the primary was taken as the first entry -- so the
real card on that machine is gone. `gpus=2` is the only reason we can tell
anything was lost, and it cannot tell us what.
This is not an edge case for this audience. Parsec, Sunshine, Moonlight,
TeamViewer and Splashtop all install one, and a cloud-gaming community is
precisely the population that has one already. A recorded gpu_model is a hard
requirement for a host; a virtual display driver satisfies it in name only.
Three changes.
Adapters are now sorted so real hardware is first, by two keys: whether the
name matches a known software adapter, then whether a vendor could be
identified at all. Order is the only signal the rest of the program has for
which GPU is "the" GPU.
The vendor comes from `AdapterCompatibility` rather than from
pattern-matching the marketing name. An "AMD Radeon" string is easy; an
OEM-rebadged one is not.
And every adapter name is now sent, not only the count. `gpus=2` told us
something had been lost and not what, which is the kind of field that wastes a
response we cannot ask again.
The known-software-adapter list has unit tests, on all platforms -- it is a
list of strings and it will need extending, so it should fail loudly rather
than quietly stop matching.
Version to 0.1.2.
For the record, what that submission got right, because none of it needed
asking: 50% of 165 Steam launch records fall in five hours of twenty-four
(21:00-01:59) against five records across the whole of 07:00-13:59. That is
0017's evening peak, measured, from one person's own files. 140 of the 165
records are titles no longer installed -- restricting the histogram to
installed titles, as review suggested, would have left 25 samples and lost the
shape entirely.
v0.1.1 is published, so the pin moves. Flipped after publishing rather than
with the version bump, so there was never a moment where the live installer
pointed at a tag that did not exist yet.
v0.1.0's added-latency grade cannot be trusted -- it measured bloat against a
median that goes unstable on a bimodally routed link -- so nothing should be
installing it.
Found by running the published one-liner, which is the only reason it was
found: `up=34Mbps rtt=188ms rttload=181ms bloat=+0ms grade=A` on a connection
that measured +115 ms and grade F three hours earlier.
The idle baseline was the median of twelve handshakes to one anycast address.
On the development connection those twelve came back **bimodal**:
[56, 56, 57, 59, 60, 176, 177, 179, 179, 179, 182, 368]
min 56 p50 177 max 368 spread 312 ms on an *idle* link
Two points of presence answering. The median therefore lands wherever the split
happens to fall, and when it lands high the loaded median comes in *below* it,
the difference goes negative, `.max(0.0)` clamps it to zero, and the headline
number reports grade A.
That is the one error direction that cannot be tolerated here. A tool whose
whole pitch is a number nobody else shows you has no business saying "your line
is fine" about a line that is not.
Bloat is now measured against the **minimum**. Queueing is delay above the
floor the path can achieve, so the floor is the baseline -- which is also how
every bufferbloat test does it. Twenty samples rather than twelve.
The distance verdict deliberately keeps the **median**, because it asks a
different question. Bloat asks how much queueing is added, so its baseline is
the best case. HOST-READY-LOCAL asks what a player will actually see, so it
takes the typical case: on a link that is bimodal between 56 ms and 180 ms, the
floor would call it near when half of all connections are not.
Both are now reported, and the gap between them is itself the finding -- a
floor of 55 ms against a typical of 180 ms says the route is the problem, which
no single number could have said.
Verified on the same connection: floor 55, typical 180, loaded 95, **+39 ms,
grade C**, verdict HOST-NET. Defensible, and no longer flattering.
Version to 0.1.1. Submissions carry it, so any row with `v=0.1.0` has a grade
that cannot be trusted.
Both installers fetched from `releases/latest/download`, which is wrong in this
repository specifically: it ships product releases as well as this tool, so
`latest` is whichever release went out most recently regardless of what it
contains.
Measured before publishing anything: `releases/latest` resolved to `v0.2.0`,
from May 2024, and the asset URL 404'd. Publishing nesdoctor-v0.1.0 would have
papered over it by becoming the newest release -- and then the first product
release after it would have moved `latest` again and broken every
`curl | sh` in the announcement, silently, for everyone, with the tool itself
untouched and nothing to point at.
Now pinned to a tag that is bumped when a nesdoctor release is cut, with
`NESDOCTOR_TAG` still overriding for testing. The download failure message also
now names the tag and says outright that an unpublished tag is the likely
cause, since that is the one mistake this arrangement invites.
Two things a dispatch on 2026-09-02 exposed.
`macos-13` is being retired and the x86_64-apple-darwin job sat queued
indefinitely waiting for a runner, while the other three targets built and
smoke-tested in under three minutes. A release should not have that as a
dependency, so Intel macOS is now cross-compiled from the arm64 runner.
The cost is real and is stated rather than hidden: an x86_64 binary cannot be
executed on an arm64 runner without Rosetta, which these images do not carry,
so it is the one target whose smoke test cannot run. The matrix carries an
explicit `smoke` flag, the step is gated on it, and the generated release notes
say which binary is unexercised. Fabricating a pass for it would have been
easy and worse.
And a tag now produces a **draft** release rather than a published one. The
binaries get attached and the notes get written, then a person reads both and
presses publish -- which is the only step in this pipeline that cannot be
undone in public.
For the record, from the successful three: the musl smoke test measured the
network from inside the static binary -- `up=1635Mbps rtt=2ms bloat=+0ms
grade=A` -- so `ring` and the platform verifier do resolve root certificates in
a fully static build. That was the one thing about this release nobody could
have known without running it.
My mistake, in a76cb2a, now merged to dev. nesdoctor writes its report
next to wherever it is run, and during development that is the
repository root. `git add -A` took it.
What the committed file exposed, all of it the operator's own machine:
- two home paths, /home/<user>/.steam/steam and .local/share/Steam
- one installed game title
- mount points
- the answers given to a test run of the questionnaire
Low severity -- the username is already public and matches the account,
and one game title is not much -- but it is exactly the class of thing
this tool exists to be careful with, and shipping it in the repository
that asks strangers to trust the tool is worse than the content.
Removed from HEAD and added to .gitignore, along with the wildcard form.
The `--json` default keeps its name on purpose: an ignore rule cannot
protect a default called something generic like report.json, and
renaming it would leave the old name unguarded for anyone who scripted
against it.
**History is not cleaned by this commit.** The file is in pushed history
on a public repository, which per our own rule about published history
means it should be treated as permanent rather than as something a
revert fixes. Rewriting dev is possible and is a judgement call about
whether the content above is worth the disruption; it is not mine to
make unilaterally.
The first executable form of our host requirements. Until now a machine
was qualified by a human reading a table of hard requirements — and a
requirement that nothing can check is one that is silently optional.
It also replaces a form. Everything we wanted from a prospective host is
measurable, and most of it **cannot be answered honestly by a human
anyway**: almost nobody knows their real upstream, and essentially
nobody has ever seen their own bufferbloat figure. What's left for the
questions is only what a machine cannot know — intent, and what someone
already pays.
## What it does
```
nesdoctor
```
- **Checks every hard requirement**: `/dev/kvm`, an AMD or Intel GPU
with a DRM render node, `VK_KHR_video_encode_queue` plus a codec,
`virglrenderer`, the two stores, the `io` cgroup controller,
`virtiofsd`. Pass / fail / **unknown**, and unknown is never collapsed
into fail — a machine we could not ask is not a machine that failed, and
losing a capable host to a missing `lspci` is the failure mode that
matters.
- **Measures upstream and, the point of the whole thing, added latency
under load.** Grade bands come from the frame budget rather than
convention: the network allowance is ~40 ms because render, encode,
decode, display and jitter buffer have already spent ~58 ms.
- **Reads Steam, only with an explicit yes**, for library size and shape
plus an hour-of-day histogram of launches — one sample per title, which
is a real distribution obtained without asking anybody anything.
- **Asks at most five questions**, branched on what was found, all
skippable.
## No server
Nothing is uploaded and no telemetry endpoint exists. The network test
talks to Cloudflare's public speed-test sink and to `1.1.1.1`, neither
of which is ours. The output is a line on the terminal that the person
may choose to paste.
The shareable line carries **no hostname, IP, username, game title or
path** — a size band rather than a size, hours rather than dates. The
long version, which does include titles and paths, stays in a local JSON
file the person is told the path of.
That is a property of the design and not a promise about our intentions:
there is nothing to switch on later.
```
nesdoctor 0.1.0 | linux/x86_64 | gpu=AMD Barcelo | cpu=12t ram=13G |
kvm=y venc=y zfs=n boxfs=n io=y | up=28Mbps rtt=179ms bloat=+19ms grade=B |
disk=91G | edge=KE/JNB | steam=1 titles/<100G | plays=20-03h n=74 |
role=- share=- pays=- | HOST-READY-LOCAL
```
## Five bugs found by running it, every one of which would have produced
wrong data
- **`vulkaninfo --summary` lists ZERO `VK_KHR_video` entries** where
full `vulkaninfo` lists five on the same machine. Preferring the summary
reported "not advertised" on a card that advertises it — a false
negative on the check most likely to disqualify a host.
- **btrfs subvolumes counted as separate disks**: `/`, `/home` and
`/srv` each reporting 91 GiB of one 91 GiB device. Now deduped by
backing device, which the two-stores check needs anyway since it wants
*separate devices*.
- **Proton and the Steam Linux Runtimes are installed like games and are
not games.** Five of eight entries on the test machine, so the title
count was 5× too high and the library-shape question was corrupted.
- **`--quiet` printed the whole questionnaire** before its summary line,
breaking the one thing `--quiet` promises. Prompts are now skipped when
output is quiet or stdin is not a terminal — and a pipe is explicitly
*not* treated as consent to read a Steam library, unlike `--yes`.
- Boot history was reporting `13.2 h/day` off **two days** of history.
Under a three-day span it now reports the span and no rate.
## One finding, now encoded as a verdict
The development connection measures **179 ms idle RTT, served from
Johannesburg**. That machine passes every other check and cannot host
for a European player, because it is distance and no upgrade shortens
it.
`HOST-READY-LOCAL` exists for exactly that case, and the wording is
deliberate:
> Every requirement passes and your uplink queues cleanly. But the idle
round trip to the nearest major network is already most of the latency
budget, and that is distance rather than a fault: no upgrade shortens
it. So this machine is a good host for people on your side of the world
and cannot be one for anybody else. **If you are somewhere without a
cloud gaming edge, that is not a consolation prize — it is the only way
anyone there gets a playable stream.**
## CI
- **`ci.yml` gains a `nesdoctor` job** — fmt, `clippy -D warnings`,
test, one real run. Scoped to this member deliberately: the rest of the
Rust half has never been under CI, so `--workspace` would turn every PR
red for unrelated reasons. Widen it one member at a time.
- **`release-nesdoctor.yml`** builds four targets on tag `nesdoctor-v*`
— x86_64 linux-musl, x86_64 windows-msvc, aarch64 and x86_64 macOS —
with `SHA256SUMS`. musl rather than glibc so one Linux binary runs on
every distro.
The step that justifies the workflow **runs the binary it just built,
network included**. `ring` under rustls resolves root certificates
through the host trust store, so a static musl build can compile cleanly
and then fail TLS on the machine it ships to — breaking the network
test, silently, and only for other people. The step fails the build if
the summary line comes back `net=unmeasured`.
## Dependencies
Four: `anyhow`, `clap`, `serde`, `ureq`. The VDF parser, every platform
probe and the text wrapping are in-tree. A binary handed to strangers
has a dependency tree that is part of its interface, so anything that
could be done with `std` is.
4 MB release binary.
## What it deliberately does not claim
- **A pass is not a promise.** Every check is a *necessary* condition,
and nothing here runs under load — a machine that passes can still fail
on block I/O.
- **The encode extension being advertised is not proof the path works.**
We have had a correct extension list over a broken path before, so that
row says so.
- **Whether `libvirglrenderer` carries the native-context patches cannot
be determined from outside**, so that row reports presence only and
stays `unknown` rather than `pass`.
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
The PR adds the nesdoctor host-readiness executable, local Steam
analysis, network measurement, installers, CI validation, and
multi-platform release packaging. Two attempted correctness fixes remain
incomplete:
- physical disk deduplication does not resolve common device-mapper
source names before comparing backing devices
- unknown historical Steam appids can still be counted as game launches
without passing runtime filtering
<h3>Confidence Score: 3/5</h3>
The PR is not yet safe to merge because shared LVM-backed stores can be
reported as physically independent and unknown Steam tools can still be
reported as game launches.
The new disk resolver fails open for common device-mapper names,
preserving a false host-readiness verdict, while Steam history still
counts absent appids without determining whether they are games or
runtime tools.
**Files Needing Attention:** apps/nesdoctor/src/sys.rs,
apps/nesdoctor/src/hostreq.rs, apps/nesdoctor/src/steam.rs
<h3>Important Files Changed</h3>
| Filename | Overview |
|----------|----------|
| apps/nesdoctor/src/sys.rs | Adds system and disk discovery, but
unresolved device-mapper names undermine physical-backing comparisons. |
| apps/nesdoctor/src/hostreq.rs | Implements host requirement verdicts
and uses physical-device sets that can falsely classify shared LVM
backing as independent. |
| apps/nesdoctor/src/steam.rs | Adds manifest and launch-history
analysis, but unknown appids bypass runtime classification and
contaminate launch metrics. |
| apps/nesdoctor/src/net.rs | Adds bounded upload-based upstream and
bufferbloat measurement; the previously reported unbounded request path
is addressed. |
| .github/workflows/release-nesdoctor.yml | Builds, smoke-tests,
packages, checksums, and publishes the four release targets. |
| .github/workflows/ci.yml | Adds focused formatting, linting, testing,
and offline execution checks for nesdoctor. |
<h3>Flowchart</h3>
```mermaid
%%{init: {'theme': 'neutral'}}%%
flowchart LR
Run[nesdoctor] --> Host[Host requirement probes]
Run --> Net[Upload and latency measurement]
Run --> Consent{Steam consent}
Consent -->|yes| Steam[Installed manifests and LastPlayed records]
Host --> Physical[Resolve filesystem sources to physical devices]
Physical --> Verdict[Host readiness verdict]
Net --> Report[Detailed JSON and shareable summary]
Steam --> Report
Verdict --> Report
```
<details><summary>Prompt To Fix All With AI</summary>
`````markdown
### Issue 1
apps/nesdoctor/src/sys.rs:369-374
**Mapper devices remain unresolved**
When root and box-store filesystems are separate LVM or dm-crypt mappings on the same physical disk, `df` supplies `/dev/mapper/...` names that do not exist under `/sys/class/block`. This branch returns those unrelated logical names unchanged, so the overlap check passes stores that still share one physical I/O queue.
### Issue 2
apps/nesdoctor/src/steam.rs:247-250
**Unknown appids bypass runtime filtering**
If `localconfig.vdf` retains `LastPlayed` data for an uninstalled Proton build, Steam runtime, or other non-game tool, its appid is absent from the installed-manifest map and this branch treats it as an uninstalled game. The tool activity then changes the launch histogram, peak window, and shareable `n` value.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
`````
</details>
<sub>Reviews (5): Last reviewed commit: ["fix(nesdoctor): three valid P1
findings
..."](7afc8929a6)
| [Re-trigger
Greptile](https://app.greptile.com/api/retrigger?id=59231233)</sub>
> Greptile also left **2 inline comments** on this PR.
<!-- /greptile_comment -->
`bun run db:push` has been failing on **every pull request** with
`error: Script not found "db:push"`. A red check has meant nothing for
as long as that's been true.
There are **two independent causes**, and fixing only the reported one
leaves the job red.
## 1. The script isn't at the root
`db:push` lives in `packages/core/package.json`; CI runs from the root.
Added root passthroughs for `db:migrate` and `db:push`, so the command
CI runs is also the one a human can run.
## 2. `drizzle.config.ts` enabled TLS for any `DATABASE_URL`
```ts
ssl: !!process.env.DATABASE_URL ? { rejectUnauthorized: false } : false
```
That's true for *any* URL — so it failed against every plain Postgres,
**including CI's own `postgres:18-alpine` service container**. And
`drizzle-kit` reports that failure as a spinner and a non-zero exit with
no message attached, which is why it would have been maddening to find
from a log.
Measured against a local container:
| | result |
|---|---|
| `DATABASE_URL` set (TLS on) | migrations fail, no error text |
| `DATABASE_URL` unset, same database | all seven apply |
TLS is now decided by the connection string: an explicit `sslmode` wins,
otherwise a local host gets none (it doesn't speak TLS at all) and any
other host gets TLS without chain verification, which is what a hosted
Postgres usually needs. The URL is parsed once rather than eight times.
## CI now applies migrations instead of `push`
`drizzle-kit push` diffs the schema against whatever is already in the
database and is a development tool — CI wants exactly what's committed
in `packages/core/migrations`. And `push` under `strict: true` asks for
confirmation, which on a runner is a **hang**, not a failure.
## Verified
Locally against `postgres:18-alpine` from an empty database, running
exactly what the workflow runs:
```
bun install --frozen-lockfile ✓
bun run db:migrate ✓ 7 migrations applied
bun test ✓ 113 pass, 0 fail, 297 expect() calls
```
Worth landing ahead of #310 so that a red check starts meaning something
again.
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
This PR repairs the database-backed web CI job by exposing core database
commands at the workspace root, applying committed migrations instead of
schema push, and selecting PostgreSQL TLS behavior from the connection
URL.
- Adds root passthrough scripts for database migration and schema push
commands.
- Adds the core `drizzle-kit migrate` command and runs it in CI.
- Disables TLS for local PostgreSQL while honoring explicit `sslmode`
settings.
- Keeps migration and test steps pointed at the same temporary CI
database.
<h3>Confidence Score: 5/5</h3>
The PR appears safe to merge, with the migration command, working
directory, connection settings, and test database remaining aligned.
The changed CI path reaches the committed migration history through the
intended core package configuration, uses plaintext for the local
PostgreSQL service, and then tests against the same migrated database;
no changed-code defect remains.
<h3>Important Files Changed</h3>
| Filename | Overview |
|----------|----------|
| .github/workflows/ci.yml | Replaces schema push with committed
migration execution while preserving the shared CI database URL. |
| package.json | Adds root-level passthroughs to the core package's
database commands. |
| packages/core/drizzle.config.ts | Parses the database URL once and
selects TLS based on explicit mode or local-versus-remote host
inference. |
| packages/core/package.json | Adds the `drizzle-kit migrate` script
consumed by the root command and CI workflow. |
<h3>Flowchart</h3>
```mermaid
%%{init: {'theme': 'neutral'}}%%
flowchart LR
PR[Pull request or main push] --> CI[Web CI job]
CI --> PG[PostgreSQL 18 service]
CI --> Install[Bun frozen install]
Install --> Root[Root db:migrate script]
Root --> Core[packages/core db:migrate]
Core --> Config[drizzle.config.ts]
Config --> Migrations[Committed migrations]
Migrations --> PG
PG --> Tests[Bun tests]
```
<sub>Reviews (1): Last reviewed commit: ["fix(ci): the web job has been
failing
on..."](203e882fbd)
| [Re-trigger
Greptile](https://app.greptile.com/api/retrigger?id=59430932)</sub>
<!-- /greptile_comment -->
`apps/nescapture/Cargo.toml` carried `[profile.release]` with `opt-level = 3`
and `lto = "thin"`. Cargo only reads `[profile.*]` from the workspace root and
warns about a member that writes one, so `cargo build --release --workspace`
— which is what build/Dockerfile runs — ignored it. The Vulkan capture layer
that ends up in the guest image was built at the default release profile, and
the warning saying so scrolled past on every build.
`opt-level = 3` is already the release default, so `lto = "thin"` is the only
part that was actually lost. It moves to the workspace root, where Cargo
reads it, and now applies to all five members — the same rule as
`[workspace.dependencies]` right above it: what must not differ between
members is stated once.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Three places where build/ said something the tree does not do.
- fstab mounted `/` as `rw`. A box is started with `ro` on the kernel
command line and `is_read_only: true` on the root device (every config in
nesbox's tree agrees: examples/vm.json, test.json, run.local.json), so the
virtio-blk device rejects writes whatever fstab asks for. `rw` here only
made OpenRC's `root` service attempt a remount that has to fail. The
Dockerfile already depended on the truth — it pre-creates /nestri/* at
build time precisely because a runtime mkdir gets EROFS — so this makes
fstab agree with the comment that was already right.
- build/README.md said nesbox's jail image "extracts Mesa and virglrenderer"
from this base. It extracts only Mesa. virglrenderer is the host half of
the native-context protocol and nesbox builds its own, patched, from
nesbox/patches/; nothing in this image carries it at all.
- conf.d/nestri-user-env called the zink driver-forcing block "load-bearing"
directly above three exports that are commented out, here and in the
profile.d copy. Whether they should come back is a separate question; a
comment insisting disabled lines are load-bearing tells the next reader
the opposite of what the file does. The reasoning is kept, because it is
still the reason to re-enable them, along with why both copies have to
move together.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## What
Adds `build/` — a Dockerfile with `mesa-build`, `nestri-build`,
`os-base`, `runtime`, `runtime_prod` and `runtime_debug` stages, plus
the `etc/` overlay, `mkimage.sh` and a `Makefile` — laid out the way
[borealis](https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/main/project-borealis)
lays out its own `build/`. This moves the guest rootfs formula into this
repo, targeting the four open guest components already here: `nescope`,
`neshub`, `neswire`, `nescapture`.
## Two structural properties worth calling out
- **No privileged host chroot.** A bare `chroot` into a hand-extracted
rootfs needs `/proc`, `/sys`, `/dev` bind-mounted in first. `os-base`
here is `FROM artixlinux/artixlinux:base-openrc` directly with `pacman
-S` as plain `RUN` steps — a Docker build step already has its own
`/proc`/`/sys`/`/dev`.
- **No host-side ownership bug to guard against.** `COPY --from=` runs
as root inside the build with no invoking-user uid in the loop.
## Scope boundary
**Deliberately excludes Proton and Valve's `steamclient.so`** — both
closed, and `CLAUDE.md` forbids closed content in this repo.
`runtime_prod`, tagged `nestrilabs/nestri:base`, is a complete,
bootable, Steam-less image — and also the shared foundation other builds
start from. Whatever layers Proton/Steam on top of it is a closed build
outside this repo, by design.
## Known gap
Nothing starts a payload yet — `nesinit` isn't open code — so
`/etc/init.d/nescope` boots it in plain-compositor mode (no command
after `--`) rather than running a game. Real and testable, just not a
full session yet. Details in `build/README.md`.
## Status
Built and tagged locally as `nestrilabs/nestri:base` (podman, no
`--no-cache` issues, greptile's three findings all fixed and verified
against a real build). Not yet packed into a disk image or run inside
nesbox.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
The PR adds a multi-stage Artix/OpenRC guest-rootfs build for the open
Nestri components, with production and debug image flavors.
- Builds patched Mesa and the Rust workspace in dedicated builder
stages.
- Assembles and configures the bootable guest environment and OpenRC
services.
- Packs a selected container image into an ext4 root filesystem while
retaining rootless container storage access.
<h3>Confidence Score: 5/5</h3>
The PR appears safe to merge.
No blocking failure remains.
<h3>Important Files Changed</h3>
| Filename | Overview |
|----------|----------|
| build/Dockerfile | Defines the complete multi-stage build, overlays
repository-root-relative configuration paths, and creates production and
debug runtime targets. |
| build/Makefile | Provides consistent image build and packing targets
using a repository-root context and matching image tags. |
| build/scripts/mkimage.sh | Keeps container-runtime operations in the
invoking user's storage while escalating only filesystem creation and
mounting operations. |
| build/etc/conf.d/nestri-user-env | Supplies the shared service
environment and export function required by the OpenRC service scripts.
|
| build/etc/init.d/guest-net | Configures optional guest networking from
kernel parameters or stable defaults. |
| build/etc/init.d/neswire | Starts the audio sink after its
dependencies and pins it as the PipeWire default once the graph is
ready. |
<h3>Flowchart</h3>
```mermaid
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Arch builder] --> B[Mesa build]
A --> C[Nestri workspace build]
D[Artix OpenRC base] --> E[Common runtime]
B --> E
C --> E
F[build/etc overlay] --> E
E --> G[runtime_prod]
E --> H[runtime_debug]
G --> I[Container image]
H --> J[Debug container image]
I --> K[mkimage.sh]
J --> K
K --> L[ext4 rootfs]
```
<sub>Reviews (6): Last reviewed commit: ["refactor(build): rename the
published
im..."](6fecc8cc31)
| [Re-trigger
Greptile](https://app.greptile.com/api/retrigger?id=58981739)</sub>
<!-- /greptile_comment -->
All three came across with their standalone repos and none had been
touched since the transport changed.
nescapture claimed to packetize with Reed-Solomon FEC and stream RTP/UDP
to a Moonlight client. It sends encoded frames to neshub over a Unix
socket. packetizer.rs, control.rs and shard_batch.rs do not exist, and
neither does ARCHITECTURE.md. Nine documented environment variables are
not read by anything -- NESCAPTURE_RTP_HOST was listed as *required* --
and five that are read were undocumented, including the one that says
where frames go. Someone following that quick start would have set a
required variable that does nothing and got no output.
Documented the three sockets, since nescapture binds one and connects to
two and that was written down nowhere.
neswire documented --rtp-addr and --channels against a gstreamer pipeline.
It has --ipc-path, --channels, --packet-duration-ms and
--bitrate-per-channel, and hub-stub exists precisely so it can be tested
without a hub. Kept the reason hub-stub decodes rather than counts bytes:
Opus codes silence at ~3 kbps, so a dead sink looks alive on a meter.
nescope was mostly right. It called the capture layer "vkcapture", listed
seven of fifteen modules and five of nine flags, and its TODO list was
three items that neshub and nescapture now do. Added compositor mode,
which is the shape a real session uses and was undocumented.
All three licence lines were "TBD" or "See project repository".
The payload-independence rule is the one thing about this repo that is
easy to violate by being helpful. Stating it where it will be read before
the first edit is cheaper than catching it in review.
Six comments across nescope, neswire and nescapture still named
nestri-guest-hub, plus one still naming nestri-protocol. Deferred from the
import commits so the rename would read as one change rather than six
unexplained edits inside otherwise-verbatim trees.
Comments only. Realigned an ASCII box in encode.rs that the shorter name
knocked crooked.
The component nescapture, neswire and nescope all talk to, and the only
thing in the guest that speaks to the client. It muxes their frames into
one iroh QUIC endpoint and fans input back.
Renamed from nestri-guest-hub, which named a location rather than a job.
Four files came across unchanged -- session.rs, ipc_listener.rs,
ticket.rs, screenshot.rs. Between them they mention Steam zero times, and
they import only nesprotocol's open modules; the control feature carrying
LaunchIntent and SteamIdentity is used exclusively by the three files that
are staying closed. The two clusters shared a main.rs and nothing else, so
there was no untangling to do -- only a cut.
main.rs loses --proton, --steamclient-so, --root and the game uid/gid,
and no longer ends by handing the process to a controller. It runs until
it is stopped. Deciding when the box is finished belongs to nesinit.
The ticket used to leave via that controller, so it needed a new way out:
neshub now serves it on a socket and nesinit dials for it. Listening
rather than dialling matches every other socket here and means no startup
ordering to get wrong.
Three tests, where there were none -- the ticket crosses a process
boundary as text now, so a round trip that drops a field would otherwise
be found by whoever cannot connect.
CLAUDE.md was 1,324 lines and all of it was about the TypeScript half, written
before there was another half. Every line of it loaded on every turn regardless
of what was being worked on, which is a real cost paid constantly for context
that is usually irrelevant.
Split by where it applies, so each guide loads when you are in the directory it
describes:
packages/core/CLAUDE.md 694 domain modules, fn(), actor, errors, auth
apps/api/CLAUDE.md 284 routes, registration, error flow
docs/alchemy.md 345 stages, bindings, secrets, the CLI
CLAUDE.md 72 the repo, both toolchains, two hard rules
Nothing was rewritten or dropped — the three files are the original text,
verified identical after the split. What the root file now carries is only what
is true repo-wide: the layout, the commands, where the detail lives, and the two
rules that are not style preferences. One of those is that nothing closed may
enter this repo, which is here because it has already been caught once.
The README described a streaming platform in four bullets and did not mention
that half the repository is Rust that runs inside a virtual machine. It now says
what each component does, why a micro-VM rather than a container, what is
deliberately absent, and what decides whether a thing is open — data is, capacity
is not.
It also says plainly that this is mid-rewrite and the docs are behind. Someone
arriving at a repo whose documentation does not match its tree should be told
that by the README rather than discover it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A Vulkan implicit layer that captures frames from inside the workload's own
process and encodes them on the GPU they were drawn on. Fourth and last of this
batch, imported as a tree from `nestrilabs/nescapture` on the same terms.
Filed under `apps/` rather than `crates/` despite building a cdylib. The rule
here is what a thing *is*, not what it compiles to: this is a finished artefact
that gets installed into an image beside its layer manifest, not a library
another crate in this tree depends on. `crates/` is for the latter, and putting
this there would make the distinction useless the first time someone looked.
Wired to the workspace, `nesprotocol` by path. Its description named the
transport component; that reads better as what it actually is — where the frames
go — so it says that instead.
Whole workspace builds and tests: 21 across four members.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Captures a session's audio and hands it to the transport over a local socket.
Third component in, imported as a tree from `nestrilabs/neswire` on the same
terms as the previous two.
Wired to the workspace, `nesprotocol` by path. 4 tests pass.
`bin/hub-stub.rs` is a stand-in for the transport's listener, which is what lets
this be developed and tested without the rest of a box existing. It names the
transport by its old name, and is left for the rename commit along with the two
in the compositor.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A headless Wayland compositor for a single fullscreen client, and the second
component into this repo. Imported as a tree from `nestrilabs/nescope` for the
same reason as the last one: the upstream repo is private, its history has never
been reviewed for publication, and a squash is what keeps that history from
becoming permanent here.
Wired to the workspace — versions from the root, `nesprotocol` by path instead
of a sibling directory. 8 tests pass.
It knows a lot about Steam, and all of it stays. `steam_app_*` window classes,
a launcher that exits before the game it started, a client that shows a login
screen with no Vulkan frames in it: that is third-party behaviour a compositor
for games has to handle, and describing it reveals nothing about how we are put
together. The rule is about topology, not vocabulary.
Two comments still name the transport by its old name and are left for the
commit that renames it, so that rename reads as one change rather than as
noise spread across four imports.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
First component into this repo. Renamed from `nestri-protocol` — everything
else in the family carries the `nes` prefix and this was the odd one out.
**Imported as a tree, not as history.** The upstream repo is private, so its
commits and commit messages have never been reviewed for what may be published,
and squashing avoids the failure this project has already documented once: a
repo published wholesale carries private history with it, permanently. Origin is
`nestrilabs/nestri-protocol`, and this is its state today rather than its past.
The `control` module is deliberately left behind. It carries the host↔guest
control channel, and its types are shaped by a payload that has no business
being described in a public repo — a box is supposed to be able to run anything.
It was already an optional feature that nothing here enables, so leaving it out
costs nothing today and stops a boundary from being crossed by accident.
What lands is the media protocol: frames, audio, cursor, input and stats. One
definition shared by both ends, so no two can drift silently. 9 tests pass.
One pre-existing clippy warning (`input.rs`, too many arguments) is left alone
on purpose — an import commit should be a faithful copy, and mixing a cleanup
into one makes both harder to read.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This repository has been public without one, which grants nobody any rights —
the opposite of what a public repo is for, and a blocker on opening anything
else into it. Apache 2.0 was decided for this tier; this is that decision
applied, not a new one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This repo holds both languages, so it needs both workspaces. Layout is the same
rule on each side — apps/ for what runs, crates/ and packages/ for what is
shared, split by what a thing is rather than what it is written in.
Members are empty because nothing has moved in yet. Versions are pinned once at
the root so two crates cannot disagree about a dependency.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Squashes the current state of the internal working tree onto this history.
The two trees had grown apart with no common ancestor, so this is a content
sync rather than a merge, and the published history is preserved rather than
rewritten — a force-push here would break every existing fork and clone to no
benefit.
What lands:
- Waitlist: API route, core module, and migration 0006 alongside game aliases.
- User verification.
- CI, oxfmt config, editor settings.
- Assorted fixes across the API routes and core modules.
The repository's own README, the wordmark and the per-package READMEs are kept
from this side; the internal tree had dropped them and they are what a stranger
arriving here reads first.
The marketing site in the internal tree is deliberately not here. It is a
separate product with its own repo and its own licence, and this repo is the
open one — a closed component does not belong in it regardless of how convenient
the directory looked.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
