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