2026-09-05 10:27:11 +00:00
1 changed files with 17 additions and 0 deletions
@@ -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