docs: correct two Inbox claims phase 4 shipped, both found by running it

[iancooper]

#155 merged with two false claims about the Inbox. Both were in MSSQLTransportInboxAndOutbox.md step 7, both compiled, both read plausibly, and neither was reachable by any gate this repository has. They surfaced while proving the companion sample (BrighterCommand/Brighter#4331) against SQL Server 2022 in Docker.

1. The global InboxConfiguration does nothing in a consumer-only process

Its policy arguments reach the pipeline only through CommandProcessorBuilder's ExternalBus overloads (ServiceCollectionExtensions.cs:657-676). Register no producers and the NoExternalBus branch is taken instead — and that overload accepts no inbox at all. So a receiver, which is the natural place to want an Inbox, silently gets none.

The page printed exactly that shape — AddConsumers with an InboxConfiguration and no producer — and asserted it de-duplicates.

Measured, with the Inbox table present and provisioned in both runs:

InboxMessages rows, receiver with NO producer registered : 0
InboxMessages rows, receiver WITH a producer registered  : 1

Step 7 now leads with [UseInbox], an ordinary handler attribute that does not depend on there being a bus, and keeps InboxConfiguration only as what supplies the store.

2. InboxScope is inert

0 references in src/ outside its own declaration, against a control of 43 for OnceOnlyAction. The page carried a table row advising when to pick Commands over Events. It changes nothing.

Also

• Step 10 now shows the de-duplication rather than asserting it:

  delivery 1, message id X : handler ran 1 time
  delivery 2, message id X : handler ran 0 times
    warn: UseInboxHandler  Command 01a08aef-... has already been seen
  InboxMessages rows after both : 1
  

• The failures section splits "handled twice, Inbox empty" from "handled twice, Inbox has rows" — different causes, and the first one is the trap above.

Gates

Nothing moved: link 164, pagelint 162 pages / 768 warnings, shape 161. --changed origin/master reads 1 documentation page(s), 3 code block(s) strict, 0 errors — the scope line, so the pass is not vacuous. All ten extracted blocks still compile against 10.7.0.

Why this is in tasks.md too

Added as phase 4's finding H. The point worth keeping: this is the third time in this programme that a compiling, plausible, reviewed example was wrong about behaviour, and the first where the instrument had to be a database rather than a probe. scope: has a type, a default and an XML comment — reading it harder would not have helped.

🤖 Generated with Claude Code

https://claude.ai/code/session_0146UueHL6H3zGBGTYwz7GtL