011: one surface over several contexts is normal

The board visualises the mesh, the work engine, the knowledge base and more, and
the alternative — a web application per context — is worse for everyone using
it. Composing several sources into one view is what a surface IS, so this is not
a compromise with the ownership rule.

What changes is only where it reads from: each context's interface rather than
each context's store. Most of that already exists — 56 of 126 modules carry a
tool surface, more than carry a service.

And the unified board is what keeps those interfaces honest. A view that cannot
be built from a context's interface proves the interface inadequate, discovered
where it is cheap to notice rather than the first time something else needs the
same data and quietly reaches for the store instead.

If composing many calls proves too slow, the answer is a projection the board
owns and keeps current from events, not access to somebody else's tables.

01-RESEARCH/011-the-module-graph/worked-provider.md

@@ -226,6 +226,23 @@ context reading it.
 Which is exactly what the count below shows: the problem was never surfaces. It was three other
 contexts keeping their tables in the mesh's database.
 
+**And one surface over several contexts is normal.** The board visualises the mesh, the work
+engine, the knowledge base and more, and the alternative — a separate web application per
+context — is worse for everyone who uses it. That is not a compromise with the rule; composing
+several sources into one view is what a surface *is*.
+
+What it changes is only where it reads from: each context's **interface**, not each context's
+**store**. Most of that already exists — 56 of 126 modules carry a tool surface, more than carry
+a service.
+
+**And the unified board is what keeps those interfaces honest.** If a view cannot be built from
+a context's interface, that interface is inadequate — discovered in the one place where it is
+cheap to notice, rather than the first time something else needs the same data and quietly
+reaches for the store instead.
+
+If composing many calls turns out too slow, the answer is a projection the board owns and keeps
+current from events — not access to somebody else's tables.
+
 ### Checked against the real consumers
 
 The rule's survival turned on whether every reader of the mesh's own registry could be served