一次执行有三种彼此独立的视图，而本页最重要的一点就是：它们从不混为一谈。

一条入站消息必须回答两个彼此独立的问题：它属于哪一个会话？ 以及 该运行哪一个工作流？ 把二者混为一谈是网关建模中最常见的错误，ChengOS 刻意让它们分开。

ChengOS 的后端是一套六边形架构（端口与适配器）加领域驱动设计。在这个项目里这不是口号——它由 crate 依赖图强制保证：cheng-core 不依赖数据库、不依赖 HTTP、不依赖文件系统，因此一条领...

ChengOS 里的页面不是模板文件，而是工作流的输出：每个 UI 节点描述一个区域，ui/pageroot 把它们组装起来，产出 PageLayout JSON，再由运行时渲染。

ui/rbacguard 决定用户能否抵达某条路由。它输出 GuardResult，连到 ui/route 节点的 guards 端口：

有两种不同的机制把人放进回路：

只能在编辑器里运行的工作流，是给你自己用的工具。发布把它变成别人可以使用的东西——一个带 URL 的页面、一个对话界面，或者一个供其他系统调用的接口。

渠道把一个外部即时通讯平台接到 ChengOS 的工作流上。消息从 Telegram 或 Slack 到达，平台特有的载荷被归一化成同一个消息模型，会话被解析出来，工作流随即运行。回复再沿同一个适配器发回去...

引擎建立在一条明确的设计原则之上：静态在左，动态在右；状态兜底，调度闭环。 规划只做一次，离线且无副作用；调度在运行时进行；而持久化的状态机是让整套机制可恢复（而不仅仅是快）的关键...

写一个节点是扩展 ChengOS 最常见的方式。一个节点就是：一个带派生宏的 Rust 结构体、一个有类型的输入、一个有类型的输出，以及一个函数。注册、JSON Schema 生成和属性面板界面都会由此自动...