[erikdarlingdata]

Why

docs/uat-onboarding.md merged (#2476) while the four #2479 fixes were still in flight. They have all landed, and the guide still documents the gaps as things a tester must work around.

That is worse than having said nothing. A tester who follows a workaround for a problem that no longer exists concludes the feature is missing — and the guide is the first thing a new UAT user reads.

What changed

Section	Said	Now
§1.1	install-darling.ps1 does not check for the runtimes	It refuses on missing ASP.NET Core, warns on missing Desktop (#2481)
§2.3	No one place to see your seat; you learn it a surface at a time	Seat indicator on the main window, reason in the tooltip (#2483)
§4.4	A rejected request leaves no trace; diagnose from the client	Refusals logged with the gate that rejected them (#2486)
§3.5, §4.3	Token shown once; lose it and re-onboard every client	--print-web-token / --print-mcp-token (#2487)
Part 6	Four entries claiming the above	Removed; restart-only stays, since it is still true

Detail worth keeping

• The runtime asymmetry is now stated rather than flattened: only ASP.NET Core stops the service, so it refuses; a missing Desktop Runtime just means the viewer will not open, so it warns.
• The seat indicator's honesty is documented: before the probe returns it says so, and a viewer that cannot reach the store reports that rather than claiming read-only — a status line blaming your role while the service is down sends you to fix the wrong thing.
• The reprint verbs carry their constraint: elevated, and on the box that encrypted the token, because DPAPI is LocalMachine-scoped. They write a live token to stdout, and the guide says to treat that console accordingly.
• The rate limit is described (one line per gate per source per 10 minutes, with a folded count), including that a full source budget is itself the signal the port is being scanned.

How the strings were checked

Taken from shipped source, not from the PR descriptions — the earlier round of this work had a message promising a log line nobody wrote.

• ViewerSeatIndicator.cs:63-64 → "Seat: read-only" / "Seat: read-write"
• DarlingHttpRefusalLog.cs:345 template + DescribeOutcome (>= 400 → "refused") + Describe(SourceCidr) → the quoted 403 line
• DarlingCliCommands.cs:247-248 → both verbs and their "run elevated; writes a LIVE token to stdout" caveat

Note

One draft of this added a Part 6 entry about viewer reconnect rate limiting. I had not verified it and removed it — Part 6 is the list testers are told not to file against, so an invented entry there suppresses a real report.

[claude]

Reviewed. This is a docs-only change (docs/uat-onboarding.md), no T-SQL or C# code touched, so the Lite/Darling parity and T-SQL style checks don't apply here.

Verified every claim against the cited source, not just the PR description:

• ViewerSeatIndicator.cs — Seat: read-only / Seat: read-write strings match exactly, including the "unreachable ≠ read-only" distinction the doc calls out.
• DarlingHttpRefusalLog.cs — gate names, the 10-minute DefaultWindow, per-(gate,source) keying, and the aggregate-bucket fallback all match the doc's description of the rate limit.
• DarlingCliCommands.cs — --print-web-token / --print-mcp-token exist, both documented as "run elevated ... writes a LIVE token to stdout," matching the doc's caveat.
• install-darling.ps1 — confirmed the refuse-on-missing-ASP.NET-Core vs. warn-on-missing-Desktop-Runtime asymmetry.
• The added "network blocks need a restart, and the service now says so at startup" line matches DarlingHostBinding.DescribeNetworkBlockLifetime, logged unconditionally in both loopback and LAN modes.

Also checked that removing the four Part 6 entries didn't leave any dangling "see Part 6" cross-references elsewhere in the doc — it didn't. No issues found; this is an accurate and well-sourced update. Nice touch pulling the invented rate-limiting entry per the PR note rather than leaving an unverified claim in a section testers are told not to file against.