Skip to content

docs(quickstart): the hero command needs -f net10.0, and the TFM sentence was wrong - #350

Merged
IanFrelinger merged 1 commit into
masterfrom
fix/quickstart-api-framework
Aug 17, 2026
Merged

docs(quickstart): the hero command needs -f net10.0, and the TFM sentence was wrong#350
IanFrelinger merged 1 commit into
masterfrom
fix/quickstart-api-framework

Conversation

@IanFrelinger

Copy link
Copy Markdown
Owner

Found by UAT tier 0-2: a clean clone of master inside mcr.microsoft.com/dotnet/sdk:10.0, following docs/TesterQuickstart.md verbatim.

The defect

Section 3's command does not start the API:

$ NEXO_ALLOW_MOCK=1 dotnet run --project application/src/Nexo.API
Unable to run your project
Your project targets multiple frameworks. Specify which framework to run using '--framework'.
1. net8.0
2. net10.0

Nexo.API began multi-targeting in 6e46f0fa (the .NET 10 move, #340). The page was verified before that, and its provenance line said the commands were "unchanged" — which is precisely what rotted.

This is the hero path. Everything after it on the page — submit a task, read the stored record, find the CopilotTask entry whose sourceId is the task id — is downstream of a running API, so a tester following the single documented entry point (D1) is stopped at the first interesting step. Tier 1 scored 0/9 before the fix and 9/9 after.

Every other page already had -f net10.0: CopilotMvpWalkthrough.md, demos/README.md, GettingStarted.md:116, and CONTRIBUTING.md:161, which explains the reason. Only the front door was missing it.

Also: the prerequisite sentence was wrong

Both pages claimed "The CLI and API target net10.0". True of the CLI (Nexo.CLI.csproj:5), false of the API (Nexo.API.csproj:8).

I checked the fix that would have made the sentence true — single-target the API to net10.0, matching D4 — and it would break the build: 12 files under src/Nexo.Tests.Infrastructure/Tests/API/ reference Nexo.API and are not excluded on the net8.0 leg (only Helpers/VirtualProduction/** and Tests/VirtualProduction/** are). The net8.0 target is load-bearing for cert-gate. So the sentence moved, not the csproj.

Verification

tierbeforeafter
0 — first fifteen minutes7/77/7
1 — audit trail0/99/9
2 — certification gate4/44/4

Clean clone to a CopilotTask entry in the trust log: 167s, cold package cache. The gate teeth run 16/16, matching the page's "16 tests" exactly, and both tests it names by name are discovered by the filter it prints.

The one check still red in the container is an artifact of the image, not the product: the SDK image sets ASPNETCORE_HTTP_PORTS=8080, which rebinds the host so the documented :5000 looks wrong. Verified separately on a native SDK 10 box — Now listening on: http://localhost:5000, as the page says. The UAT harness now unsets that variable so the container behaves like a tester's machine.

The harness's doc-command-verbatim check now greps the command out of the page and runs it, so this specific rot cannot recur silently.

🤖 Generated with Claude Code

…ence was wrong
UAT tier 0-2, clean clone of master inside mcr.microsoft.com/dotnet/sdk:10.0:
the API command in TesterQuickstart section 3 does not start the API. It exits
with "Your project targets multiple frameworks. Specify which framework to run
using '--framework'", because Nexo.API multi-targets net8.0;net10.0 (set by
6e46f0f in the .NET 10 move). Every later claim on the page -- submit a task,
read the record, find the CopilotTask entry in the trust log -- is downstream of
that command, so a tester following the one documented entry point is stopped at
the first interesting step.
Every other page already had it right (CopilotMvpWalkthrough, demos/README,
GettingStarted, and CONTRIBUTING, which explains the reason). Only the front
door was missing it.
Also corrects the prerequisite sentence on both pages. "The CLI and API target
net10.0" is true of the CLI and false of the API. The net8.0 target is
load-bearing, not vestigial: 12 files under src/Nexo.Tests.Infrastructure/
Tests/API/ reference Nexo.API and are not excluded on the net8.0 leg, so
single-targeting the API to match the sentence would break the net8.0 build.
The sentence had to move, not the csproj.
The page's provenance line promised commands checked on SDK 9 and "unchanged"
since; that hedge is exactly what rotted, so it now records the SDK 10 container
run that caught this.
Verified after the fix: 22 of 23 UAT checks pass, the one remaining failure
being an artifact of the container image (ASPNETCORE_HTTP_PORTS=8080 rebinds
the host); on a native SDK 10 box the API binds http://localhost:5000 as the
page says.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@cursor

cursorBot commented Aug 17, 2026

Copy link
Copy Markdown
Contributor

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

@IanFrelinger
IanFrelinger merged commit f6459d7 into masterAug 17, 2026
3 checks passed
@IanFrelinger
IanFrelinger deleted the fix/quickstart-api-framework branch August 17, 2026 18:19
IanFrelinger pushed a commit that referenced this pull request Aug 18, 2026
…mand needs no flag
#350 documented the multi-targeting because changing it looked risky: twelve
files under src/Nexo.Tests.Infrastructure/Tests/API linked Nexo.API on the
net8.0 leg, so single-targeting would have broken that build. Looked at
properly, that leg was the problem rather than the constraint -- the API ships
on net10.0 only, so those tests were exercising a framework the product never
runs on, and the cost of that coverage was a hero command in the tester
quickstart that could not start the API at all.
Tests/API now compiles on net10.0 only, alongside the VirtualProduction files
that were already scoped that way and for the same reason, and the Nexo.API
ProjectReference is conditioned to net10.0. Nexo.API single-targets net10.0, so
D4's statement ("the CLI and API target net10.0") is now simply true rather than
true-with-a-footnote.
Verified: both legs of the test project build, and
`dotnet run --project application/src/Nexo.API` starts the API with no framework
flag. The flag stays in the docs because it remains valid and keeps the command
identical across pages; the sentences that explained the multi-targeting are now
corrected, since they describe something that is no longer true. Tier 8: 4/4.
Also removes the last LINQ predicates from the copilot store's QueryAsync. They
resolve through the same LiteDB BsonMapper that proved unsafe under concurrency
in EnsureIndex, and reads here genuinely race writes -- the API queries history
while other requests store. BsonExpression with bound parameters instead, and
the `since` bound is serialised through the same mapper that wrote the documents
so the comparison is against the stored representation. 15/15 store tests pass,
including the existing since and tenant filters.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
IanFrelinger pushed a commit that referenced this pull request Aug 18, 2026
testing-strategy was right again: production wiring changed with no ProdStyle
test. It also points at a gap the previous commit left open. The docs still pass
-f net10.0, which works whether or not the host multi-targets, so re-adding a
framework to Nexo.API would break no build and no docs check -- it would only
quietly restore the trap that made the tester quickstart's hero command fail
(#350). Documentation cannot hold this invariant; the shape has to.
Asserts both shipped hosts declare <TargetFramework>, not <TargetFrameworks>,
with a failure message that says what to do if a second framework is ever
genuinely needed: update the docs in the same change and delete the test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@IanFrelinger@PlzTouchGrass