@pisell/private-materials 6.12.167 → 6.12.169

package/lib/components/HDLKiosk/docs/08-/346/227/240/345/244/264Application/350/277/220/350/241/214/346/227/266/351/207/215/346/236/204/350/256/276/350/256/241.md

@@ -0,0 +1,719 @@
+# 无头 Application Runtime 重构设计
+
+> 文档角色：定义通用 Application、Trigger、Runtime、Workflow Session 和能力绑定的实现边界。  
+> 文档状态：核心运行路径已实现；未完成项在本文单独列出。  
+> 更新日期：2026-08-24
+
+## 1. 背景与目标
+
+HDLKiosk 已把通用基础包、HDLKiosk Application Definition、Runtime Binding、
+Workflow Session 和 React Components 分开。相同 Definition 可以在纯
+JavaScript、自动化测试和 React 中运行；React Session Controller 只是 Runtime Adapter。
+
+本次重构目标：
+
+1. Kernel 不认识 HDLKiosk、React、Screen、商品、扫码、称重和支付；
+2. `app/` 只声明 HDLKiosk 业务能力协议和编排关系，不携带 Host/SDK 实现；
+3. `runtime/` 绑定 Host、Trigger Adapter 和 Operation Handler，产出可独立运行的 Runtime；
+4. Workflow 可由 manual、设备、定时等 Trigger 启动；
+5. Workflow 运行后的 Command/Intent 可完全脱离 UI 执行；
+6. React 只订阅 Snapshot，并向 Session 派发与纯 JS 相同的指令；
+7. 一个 Application 可以包含多个 Workflow，Runtime Policy 决定允许多少个活跃 Session；
+8. 当前自动 Trigger 与 Workflow 一对一；重复绑定 fail-closed。
+
+非目标：
+
+- 不建设 BPMN 或远端低代码平台；
+- 不允许远端 JavaScript；
+- 不让 Workflow Kernel 解释购物车、支付或设备业务；
+- 不用隐式优先级、注册顺序或“第一个匹配”解决 Trigger 歧义；
+- 不要求第一阶段立即支持持久化和跨进程调度，但协议必须允许后续注入。
+- 当前不实现多 Workflow 共用自动 Trigger，也不实现 Workflow 嵌套调用；数据结构不阻断以后显式扩展。
+
+## 2. 核心概念
+
+### 2.1 Application Definition
+
+`defineApplication()` 产生不可变、无运行状态、无外部副作用的应用蓝图。
+
+它可以包含业务语义 ID，例如 `catalog`、`cart.addProduct`、`checkout.open`；不同 Application 正是通过这些语义区分。但它不能包含这些能力如何调用 Host、SDK、数据库或设备的实现。
+
+```ts
+const application = defineApplication({
+  id: 'hdl-kiosk',
+  activities,
+  workflows,
+  triggers,
+  operations,
+  policies,
+});
+```
+
+Application Definition 负责：
+
+- Activity 可接受的 Command 和 Intent；
+- Workflow 拓扑、起点、终点和 Trigger Binding；
+- Trigger Contract；
+- Operation Contract；
+- 静态 Policy 和协议引用完整性。
+
+Application Definition 不负责：
+
+- 创建 Actor 或 Workflow Session；
+- 订阅扫码枪或称重设备；
+- 执行 Operation；
+- 持有当前订单和页面状态；
+- 注册 React Component；
+- 连接 Host、SDK、HTTP 或数据库。
+
+### 2.2 Application Runtime
+
+`createApplicationRuntime(options)` 把一份 Application Definition 绑定到一个具体运行环境。
+
+```ts
+const runtime = createApplicationRuntime({
+  definition: application,
+  triggerAdapters,
+  sessionFactory,
+  maxActiveSessions: 1,
+});
+```
+
+Runtime 负责：
+
+- 编译并校验 Application；
+- 激活、释放自动 Trigger Adapter；
+- 接收 manual start；
+- 将 Trigger Occurrence 路由到唯一 Workflow；
+- Trigger 幂等、并发仲裁和 Admission Policy；
+- 创建、保存和查询 Workflow Session；
+- 绑定 Operation Handler；
+- 发布 Session 生命周期和 Runtime Snapshot；
+- Runtime 级 dispose。
+
+同一个 Definition 可以创建多个 Runtime，例如生产、测试、模拟器或两台不同设备上的运行实例。
+
+### 2.3 Workflow Session
+
+Workflow Session 是某一 Workflow Definition 的一次具体执行实例。Kernel 内部持有 Workflow Instance/Actor；外部通过 Session Handle 使用它。
+
+```ts
+interface WorkflowSession {
+  readonly id: string;
+  readonly workflowId: string;
+
+  getSnapshot(): WorkflowSessionSnapshot;
+  subscribe(listener: () => void): () => void;
+  dispatch(instruction: WorkflowInstruction): Promise<DispatchResult>;
+  cancel(reason?: string): Promise<CancelResult>;
+}
+```
+
+一个 Runtime 可以管理零到多个 Session。HDLKiosk 使用 Runtime Admission Policy 限制同一设备最多一个活跃 Session；这不是 Kernel 固有限制。
+
+为避免和销售 Host 的会话混淆：
+
+- Kernel/Runtime 使用 `WorkflowSession` 或 `WorkflowInstance`；
+- 销售侧使用 `CommerceSession` 或 `HostSession`；
+- 不再用裸 `session` 同时指代两种生命周期。
+
+### 2.4 Presentation Binding
+
+Presentation 是可选 Adapter，不进入 Application Definition 和 Runtime 必需依赖。
+
+```ts
+const presentation = definePresentationBindings({
+  identity: IdentityScreen,
+  catalog: CatalogScreen,
+  paymentMethod: PaymentScreen,
+});
+```
+
+无 Presentation 时，Application 仍可启动 Session、执行 Command/Intent 并完成 Workflow。
+
+## 3. 总体关系
+
+```text
+Application Definition
+  ├── Activity Contracts
+  ├── Workflow Definitions
+  ├── Trigger Contracts / Bindings
+  ├── Operation Contracts
+  └── Static Policies
+             │
+             │ createApplicationRuntime(definition, bindings)
+             ▼
+Application Runtime
+  ├── Trigger Adapters
+  ├── Admission / Idempotency
+  ├── Session Registry
+  └── Workflow Sessions
+          ├── quick #1
+          ├── barcodeScan #2
+          └── weighingProduct #3
+
+Presentation Bindings ──订阅 Runtime/Session──► React UI
+Pure JavaScript ────────调用 start/dispatch───► Runtime/Session
+```
+
+生命周期关系：
+
+```text
+Definition：进程/模块级，不执行副作用
+Runtime：设备、页面容器或服务实例级
+Session：单次 Workflow 执行级
+React Component：Presentation 生命周期；不得拥有 Session 的事实生命周期
+```
+
+## 4. Instruction 模型
+
+UI、测试和纯 JavaScript 必须使用同一套 Instruction API。
+
+### 4.1 Command
+
+Command 请求当前 Activity 执行一项业务能力，但不天然表示完成当前节点。
+
+```ts
+await session.dispatch({
+  type: 'command',
+  activityId: 'catalog',
+  command: 'selectProduct',
+  input: { productId: 'p1', quantity: 1 },
+  idempotencyKey: 'select:p1:1',
+});
+```
+
+登录、选择商品、更新数量和流程内扫码通常属于 Command。
+
+### 4.2 Intent
+
+Intent 请求当前 Activity 产生 Resolution，并可能触发节点迁移。
+
+```ts
+await session.dispatch({
+  type: 'intent',
+  activityId: 'catalog',
+  intent: 'complete',
+  idempotencyKey: 'catalog:complete:1',
+});
+```
+
+Runtime 必须验证 Activity、当前 Step、Session Epoch、允许的 Command/Intent 和幂等键，调用方不能直接按 Operation ID 绕过 Activity Contract。
+
+## 5. Trigger 模型
+
+### 5.1 三个不同概念
+
+```text
+Trigger Contract
+  定义一种启动信号协议，例如 manual、onScan、onWeightChanged
+
+Trigger Adapter
+  在具体 Runtime 中连接按钮之外的外部来源，例如 device.subscribe
+
+Trigger Occurrence
+  某一次具体点击、扫码、称重边沿或定时到达
+```
+
+Trigger 是创建新 Workflow Session 的桥梁，不负责向已有 Session 派发业务 Command。
+
+入口扫码与流程内扫码必须分离：
+
+```text
+没有活跃 Session：扫码 → onScan Trigger → 创建 barcodeScan Session
+已有业务 Session：扫码 → consumeBarcode Command → 当前 Session
+```
+
+称重同理：
+
+```text
+Entry 阶段重量边沿 → onWeight Trigger → 创建 weighingProduct Session
+Workflow 内持续读数 → updateWeight Command/Projection → 当前 Session
+```
+
+### 5.2 Workflow 默认 manual
+
+作者未声明 `start` 时，等价于绑定内置 `manual` Trigger：
+
+```ts
+defineWorkflow({
+  id: 'quick',
+  steps,
+});
+```
+
+等价于：
+
+```ts
+defineWorkflow({
+  id: 'quick',
+  start: {
+    trigger: 'manual',
+    channel: 'quick',
+  },
+  steps,
+});
+```
+
+默认值只允许存在于作者 DSL。Compiler 必须把它显式化到编译结果。
+
+Manual 调用必须指定 Workflow，不能提供有歧义的 `application.start(payload)`：
+
+```ts
+const session = await runtime.workflow('quick').start(payload);
+```
+
+内部仍统一转换为一次定向的 manual Trigger Occurrence。
+
+### 5.3 Trigger 节点是作者侧虚拟节点
+
+编排器可以把 Trigger 表现成开始节点，但它不能成为 Actor 中的普通 Step。Trigger 发生前 Session 尚不存在，不可能先创建 Actor 再等待一个负责创建 Actor 的节点。
+
+```text
+作者视图：Manual Start → Identity → Catalog → Payment
+编译结果：startBinding=manual/quick，initial=identity，nodes 不含 Trigger
+```
+
+Trigger 不进入导航历史、completed steps 或 Activity Surface。
+
+## 6. Channel 与自动 Trigger 唯一绑定
+
+### 6.1 唯一地址
+
+`triggerType + channel` 构成启动地址：
+
+```ts
+defineWorkflow({
+  id: 'barcodeScan',
+  start: {
+    trigger: 'onScan',
+    channel: 'product',
+  },
+  steps,
+});
+```
+
+当前强约束更简单：除内置 manual 外，一个自动 Trigger 只能属于一个 Workflow。
+即使 Channel 不同，重复绑定也在 Application 定义阶段失败。Channel 仍被保留为稳定的
+逻辑入口地址，避免未来扩展时改变 Trigger Occurrence 和 Session Cause 协议。
+
+### 6.2 Channel 不必来自原始设备事件
+
+Channel 是 Application Runtime 的逻辑路由键，不要求物理事件天然携带它。
+
+原始称重事件通常只有：
+
+```ts
+{
+  type: 'weightChanged',
+  grams: 1260,
+  deviceId: 'scale-1',
+}
+```
+
+它没有 `channel` 并不影响当前实现。HDLKiosk Scale Trigger Adapter 在绑定时固定发出
+`weighing-product` Channel；物理设备和 Workflow 不互相认识。
+
+### 6.3 称重事件实现
+
+同一把秤在当前 Runtime 中通常只有一个入口用途。由装配配置指定逻辑 Channel：
+
+```ts
+createHDLKioskEntryTriggerAdapters(host, config)
+```
+
+对应 Workflow：
+
+```ts
+defineWorkflow({
+  id: 'weighingProduct',
+  start: {
+    trigger: 'onWeight',
+    channel: 'weighing-product',
+  },
+  steps,
+});
+```
+
+如果以后需要一个 Trigger 绑定多个 Workflow，必须新增显式路由/启动计划语义；当前不会
+根据 Channel、注册顺序或优先级自动推断。
+
+### 6.4 Trigger Adapter 单例与 Admission
+
+同一种物理 Trigger Adapter 在一个 Runtime 内只订阅一次，不能因为三个 Workflow 引用 `onWeight` 就注册三次设备监听。
+
+Trigger 路由顺序：
+
+```text
+External Event
+→ Adapter normalize/deduplicate
+→ resolve Channel
+→ find unique Workflow Binding
+→ Runtime Admission Policy
+→ create Session
+→ publish Session Started
+```
+
+HDLKiosk 已有活跃 Session 时，入口 Trigger 默认被 Admission Policy 拒绝。Trigger 不会把事件自动转发给当前 Session；流程内事件必须通过显式 Command 通道处理。
+
+## 7. 自动 Trigger 启动后的 Session 获取
+
+Manual start 可以直接返回 Session：
+
+```ts
+const session = await runtime.workflow('quick').start(payload);
+```
+
+自动 Trigger 没有同步业务调用方，因此 Runtime 必须拥有 Session Registry 和可回放生命周期观察接口：
+
+```ts
+runtime.sessions.subscribe((event) => {
+  if (event.type !== 'started') return;
+  const session = runtime.sessions.get(event.sessionId);
+});
+
+runtime.sessions.listActive();
+runtime.sessions.findActive({ workflowId: 'barcodeScan' });
+runtime.sessions.get(sessionId);
+```
+
+Runtime 应先允许消费者订阅，再通过 `activate()` 激活自动 Trigger：
+
+```ts
+const runtime = createApplicationRuntime(application, bindings);
+const unsubscribe = runtime.sessions.subscribe(listener);
+runtime.activate();
+```
+
+即使消费者晚到，也可以通过 `listActive()` 或 Runtime Snapshot 找回 Session，不能只依赖一次性事件。
+
+Session started 事件至少包含：
+
+```ts
+interface WorkflowSessionStartedEvent {
+  readonly type: 'started';
+  readonly sessionId: string;
+  readonly workflowId: string;
+  readonly workflowVersion: string;
+  readonly trigger: {
+    readonly type: string;
+    readonly channel: string;
+    readonly occurrenceId: string;
+  };
+}
+```
+
+Trigger Adapter 的 `emit()` 可以返回 `sessionId`、duplicate/rejected 状态供设备确认和遥测使用，但不把完整 Session Handle 暴露给 Adapter。Adapter 不负责继续驱动业务流程。
+
+## 8. Operation Contract 与 Handler 分离
+
+当前带 `execute` 的 Operation 同时承担协议和 Host 业务实现，必须拆分。
+
+### 8.1 Application 中的 Contract
+
+```ts
+const cartAddProduct = defineOperationContract<
+  CartAddProductInput,
+  CartMutationResult
+>({
+  id: 'cart.addProduct',
+  effect: 'write',
+  conflictScope: 'cart',
+  retry: 'explicit-user',
+  timeoutMs: 20_000,
+});
+```
+
+Contract 可以声明影响编排安全的稳定元数据：
+
+- 输入/输出类型；
+- read/write effect；
+- conflict scope；
+- timeout；
+- retry/idempotency 语义；
+- policy tags。
+
+Contract 不包含 `execute`、Host、SDK 或数据库实例。
+
+### 8.2 Runtime 中的 Handler
+
+```ts
+const cartAddProductHandler = bindOperation(
+  cartAddProduct,
+  async ({ services }, input, signal) =>
+    services.sales.addProduct(input, signal)
+);
+```
+
+Handler 负责：
+
+- 调用 Host/SDK/HTTP/数据库；
+- 具体一致性屏障；
+- 错误归一；
+- 写后验证；
+- 生产实现差异。
+
+同一个 Definition 可以绑定 production、fake 和 simulation Handler。
+
+## 9. Trigger Contract 与 Adapter 分离
+
+Application 只声明 Trigger 协议：
+
+```ts
+const onWeight = defineTriggerContract<WeightOccurrence>({
+  id: 'onWeight',
+  mode: 'automatic',
+});
+```
+
+Runtime Binding 才允许订阅设备：
+
+```ts
+const onWeightAdapter = bindTriggerAdapter(
+  onWeight,
+  ({ services, emit }) => services.scale.subscribe(/* ... */)
+);
+```
+
+`defineApplication()` 不执行 `subscribe()`；`runtime.activate()` 才安装订阅，`runtime.dispose()` 必须释放订阅。
+
+内置 `manual` Trigger 不需要 Adapter。
+
+## 10. Activity 与 UI 分离
+
+目标 Activity Contract：
+
+```ts
+const catalog = defineActivity({
+  id: 'catalog',
+  commands: {
+    selectProduct: cartAddProduct,
+    consumeBarcode: barcodeConsume,
+  },
+  intents: {
+    complete: {
+      precondition: 'cart.notEmpty',
+      navigate: 'next',
+    },
+  },
+});
+```
+
+Activity 不强制声明 `surface.id`。React View 在独立 Presentation Binding 中注册。Activity 的数据读取应通过 Runtime Snapshot、Query/Projection Contract 或外部 selector 提供，不把 React Props 模型写入 Kernel。作者 API 已统一使用 `defineApplication()` 和中性的 Application/Slice 类型；Kernel 仅携带 `surfaceId`，不解释 Screen。
+
+## 11. 目标 API 草案
+
+```ts
+const definition = defineApplication({
+  id: 'hdl-kiosk',
+  activities: [identity, catalog, paymentMethod, paymentCompleted],
+  workflows: {
+    quick,
+    barcodeScan,
+    weighingProduct,
+  },
+  triggers: [manual, onScan, onWeight],
+  operations: [
+    identityLogin,
+    cartAddProduct,
+    barcodeConsume,
+    checkoutOpen,
+  ],
+  policies: {
+    maxActiveSessions: 1,
+  },
+});
+
+const runtime = createApplicationRuntime(definition, {
+  operations: productionOperationHandlers,
+  triggers: {
+    onScan: scannerAdapter,
+    onWeight: weighingEntryAdapter,
+  },
+  predicates: productionPredicates,
+  services: { sales, devices, telemetry },
+});
+
+runtime.sessions.subscribe(renderOrObserveSession);
+runtime.activate();
+
+const quick = await runtime.workflow('quick').start({ locale: 'en' });
+
+await quick.dispatch({
+  type: 'command',
+  activityId: 'catalog',
+  command: 'selectProduct',
+  input: { productId: 'p1' },
+  idempotencyKey: 'select:p1:1',
+});
+```
+
+## 12. 编译和激活校验
+
+### 12.1 Definition 编译期
+
+至少校验：
+
+- Workflow、Activity、Operation、Trigger ID 唯一；
+- 所有引用已注册；
+- 默认 manual 已显式化；
+- `(triggerType, channel)` 唯一；
+- 自动 Trigger Binding 有非空 Channel；
+- manual Channel 可稳定定位 Workflow；
+- Trigger 虚拟节点不进入 Actor nodes；
+- Workflow initial、可达性、终点和 transition 合法；
+- Activity Command 只引用 Operation Contract；
+- Definition 不含 Presentation/Host 实现。
+
+### 12.2 Runtime 激活期
+
+至少校验：
+
+- 所有非 manual Trigger Contract 有 Adapter；
+- 所有 Operation Contract 有 Handler；
+- Predicate/Guard Provider 完整；
+- 一个 Trigger Adapter 不被重复激活；
+- Runtime Profile 的静态 Channel 存在唯一 Workflow Binding；
+- Adapter setup 失败时 Runtime 不进入 active；
+- 已安装订阅在部分激活失败时全部回滚。
+
+### 12.3 Occurrence 运行期
+
+至少校验：
+
+- occurrence ID 非空且在 Trigger 范围内幂等；
+- Channel 路由结果唯一；
+- Binding 存在；
+- Admission Policy 允许新建 Session；
+- payload 通过目标 Workflow start contract；
+- Runtime 未 disposed；
+- 同一 Occurrence 重放返回 duplicate/existing，不重复创建 Session。
+
+## 13. 安全不变量
+
+1. Trigger 只创建 Session，不驱动已有 Session 的业务 Command；
+2. 不能唯一选择 Workflow 时，一个 Session 都不创建；
+3. 不使用数组顺序、注册顺序或默认 priority 消除歧义；
+4. 同一 Trigger Adapter 在一个 Runtime 中至多一个有效订阅；
+5. Runtime 拥有 Session 生命周期，React 卸载不天然终止 Session；
+6. Command 必须通过当前 Activity Contract，不能直接执行任意 Operation ID；
+7. Application Definition 不持有 Host/SDK/React/设备实例；
+8. Operation Contract 与 Handler 分离；
+9. Trigger Contract 与 Adapter 分离；
+10. 自动启动的 Session 必须进入 Registry，并可由迟到消费者查询；
+11. Terminal 仅表示结构终点，业务完成条件由 Application Policy、Predicate 和 Operation 结果保证；
+12. Runtime dispose 后拒绝新的 Trigger、start 和 dispatch，并释放所有订阅与执行资源。
+
+## 14. 实际目录与依赖边界
+
+```text
+kernel/
+├── application/            # 通用 Application、Slice、Trigger、Runtime/Registry 协议
+├── workflow/               # Compiler、Actor、Transition 原语
+└── operations/             # 与业务无关的 Operation 调度原语
+
+app/
+├── manifest.ts             # HDLKiosk Application Definition 实例
+├── contracts/              # Application 对 Host/Runtime 的稳定业务端口
+├── operations.ts           # HDLKiosk Operation Contracts，无 Handler
+└── workflow/               # quick/barcode/scale 业务拓扑与策略
+
+slices/                     # 按 feature 并置 slice.ts 协议与 React View/Screen
+
+runtime/
+├── createRuntime.ts        # 绑定 Host 并产出可执行 Runtime
+├── triggers.ts             # Scanner/Scale Trigger Adapter
+├── devices/                # 无 UI 设备 ingress、去重与 Scale Store
+├── operations/             # Host Operation Handler
+└── session/                # Session/Actor/Context/Lifecycle 具体组合
+
+ui/
+├── controllers/            # React 对 Runtime/Session 的适配
+├── entry/                  # Workflow 外的手动入口 UI
+├── ScreenRenderer.tsx
+└── views.ts                # Activity → React View
+
+components/                 # 跨 Slice 的 common/shell/overlay 视觉组件
+```
+
+固定依赖方向是：
+
+```text
+kernel ← app ← runtime ← ui
+           ↑              ↑
+         slices ───────────┘
+```
+
+`app/contracts` 归 HDLKiosk Application 所有；`app` 可依赖通用 `kernel`，并且
+只通过 `slices/*/slice.ts` 使用 Activity 协议，不可依赖 `runtime` 或 React。
+`runtime` 可依赖 `app/kernel` 并绑定具体 Host Port，但不可依赖 React。`ui` 和
+`components` 是可选消费者。`architectureBoundary.test.ts`、
+`kernel/dependencyBoundary.test.ts` 和 `components/dependencyBoundary.test.ts` 共同守住这些规则。
+
+## 15. 实现状态
+
+已经实现：
+
+1. 默认 manual、显式自动 Trigger 和当前唯一绑定校验；
+2. 无 React Application Runtime、统一启动管道、Session Registry、幂等和单会话准入；
+3. HDLKiosk manual/Scanner/Scale 的无头启动，Scanner/Scale 由 Runtime Adapter 直接订阅 Host；
+4. React Session Controller 改为 Runtime Adapter；
+5. Operation Contract 与 Runtime Handler 完全分离；
+6. Activity 的 Surface Contract 可选；
+7. 自动 Session 可通过 Registry 和 lifecycle event 获取。
+8. 物理目录已经按通用基础包、HDLKiosk App、无头 Runtime、React UI 分层；Slice 协议与 UI 按 feature 并置；
+9. 业务 Actor 集成测试移出 Kernel，Kernel 单元测试不再借用 HDLKiosk 错误模型。
+10. 作者 API 已去除 `Kiosk*` 命名，Kernel 中的 `screenId` 与 Checkout 专用字段已改为中性协议。
+
+仍需完成：
+
+1. 让 Runtime 在激活时显式校验全部 Operation Handler/Predicate Binding；
+2. 增加一个完整无 UI Command + Intent 到 Terminal 的 E2E。
+
+## 16. 验收标准
+
+### 16.1 无头执行
+
+- 不加载 React 即可创建 Runtime；
+- manual 启动 Quick 并通过 Command/Intent 完成流程；
+- Fake Handler 能替换全部 Host Handler；
+- Runtime Snapshot 与 React 环境一致。
+
+### 16.2 Trigger
+
+- 未声明 Trigger 的 Workflow 编译为 manual；
+- 多个 manual Workflow 可由显式 Workflow Handle 各自启动；
+- 同一自动 Trigger 被两个 Workflow 引用时定义失败；
+- 称重物理事件不带 Channel 仍能由 Adapter 启动唯一 Scale Workflow；
+- 同一 occurrence 重放不重复创建 Session；
+- Runtime dispose 后设备事件不能启动 Session。
+
+### 16.3 Session 获取
+
+- manual start 直接返回 Session；
+- automatic start 发布包含 occurrence correlation 的 started 事件；
+- 晚挂载消费者可以从 Registry 找到活跃 Session；
+- React 卸载/重挂不丢失 Runtime 拥有的 Session；
+- HDLKiosk 单 Session Admission 在扫码、称重、manual 并发时只接受一个。
+
+### 16.4 解耦
+
+- Kernel 不 import HDLKiosk contracts、React 或 BigSale；
+- Application Definition 不出现 `execute`、`host`、React Component 或设备实例；
+- Presentation 缺失不阻止无头 Workflow 执行；
+- Operation/Trigger 的生产、Fake 和模拟 Binding 可互换。
+
+## 17. 首期明确决策
+
+以下决策在实施过程中不再重复开放：
+
+1. Workflow 默认 Trigger 是 manual；
+2. Manual API 始终显式选择 Workflow；
+3. Trigger 在作者侧可显示为节点，编译后是 start binding，不进入 Actor；
+4. Channel 是逻辑路由键，不要求来自物理事件；
+5. 当前一个自动 Trigger 只绑定一个 Workflow；
+6. Channel 由 Trigger Adapter 提供，不要求物理事件携带；
+7. 当前不支持 broadcast 或 Workflow 嵌套，未来扩展不得绕过统一启动管道；
+8. 自动 Session 通过 Runtime Registry 和生命周期事件暴露；
+9. Application Definition 声明 Contract，Runtime Binding 提供实现；
+10. UI 是可选 Presentation Adapter，不拥有业务执行和 Session 生命周期。