上一篇讲多台设备汇到一屏。这一篇反过来：一台设备开成多个画面。
回到驾驶室
设备（MCP 服务器 + 画面描述）
├── 驾驶室控制台 → 全部控制权
├── 机舱终端 → 部分控制 + 详细仪表
├── 船长平板 → 仪表盘 + 警报
└── 个人手机 → 只看状态同一台设备。从哪里接入，打开的东西就不同。
关键不是每个通道一个画面，而是每个通道一个权限等级的画面。不是手机上把阀门按钮藏起来，而是那个画面里本来就没有那个按钮。
而定这些等级的，是描述设备的一方。设备是画面的主人，那么给谁看什么、让谁碰什么，也由设备来定。
杂志里已经有这个形状的样例。一台服务器按接入的机器，分别给出自助点单画面、收银画面、厨房画面。三个画面互不相同，应用只有一套。
验证的主体不变
这在安全攸关的领域是决定性的。
船舶和重型设备不让外部软件进来，不是因为性能，而是责任归属。出了事故谁来负责。所以把控制权交到外面的结构，在被讨论之前就被筛掉了。
看这个结构里有什么越过了边界，答案就出来了：没有。
设备厂商按规范自己动手移植，自己定每个通道的等级。画面描述是他们的，工具是他们的，暴露什么也由他们决定。这边提供的是规范，和把它画出来的运行时。
不把控制权交出去，也能把画面打开。 而且验证的主体留在原处。原本验证那台设备的组织，继续验证。
里面什么都没有被拿走，责任的位置也没有移动。
不做专用应用
顺带来的自由。
- 原有的仪表盘可以照旧
- 车前面可以再加一块显示器
- 客厅电视上只看状态也行
- 不再单独做平板版和手机版应用
最后一条在实务上最大。此前设备公司想给客户一块移动端画面，除了开一个应用开发项目没有别的路。做出来、过审、维护两个平台、设备一变再来一遍。
这里只是多一个通道。描述照旧，只是等级不同。
画面是接入用的窗，功能在设备里。
定等级的那一方
一台服务器按接入方给出不同画面，这一点已在样例中确认。
分成几级、哪个位置能打开什么，不由这个结构来定。由造这台设备的一方来定。 给驾驶室全部控制权、甲板只给通知，或者反过来，都在同一行声明里分开。
等级由设备来定，画面按这个决定绘出。决定本身不会离开设备。
makemind.dev 「探索」— 一台服务器按接入方给出三个画面，样例里确认过。