@pisell/private-materials 6.12.166 → 6.12.167

package/es/components/HDLKiosk/app/ScreenRenderer.js

@@ -27,7 +27,7 @@ function ScreenRenderer({ definition, snapshot, sales, send, commandState = { bu
 	const modalBaseNodeId = ((_activeNode$presentat = activeNode.presentation) === null || _activeNode$presentat === void 0 ? void 0 : _activeNode$presentat.mode) === "modal" ? activeNode.presentation.base : void 0;
 	const renderedNode = definition.nodes[modalBaseNodeId !== null && modalBaseNodeId !== void 0 ? modalBaseNodeId : snapshot.nodeId];
 	const bindActivity = (activityId) => (action) => {
-		send(action.kind === "outcome" ? _objectSpread2(_objectSpread2({}, action), {}, { activityId }) : action);
+		send(action.kind === "intent" || action.kind === "navigation" ? _objectSpread2(_objectSpread2({}, action), {}, { activityId }) : action);
 	};
 	const viewSnapshot = commandState.busy || commandState.error ? _objectSpread2(_objectSpread2({}, snapshot), {}, {
 		status: commandState.busy ? "running" : snapshot.status,

package/es/components/HDLKiosk/app/views.js

@@ -3,13 +3,14 @@ import { renderCustomization } from "../slices/customization/view.js";
 import { renderFulfillment } from "../slices/fulfillment/view.js";
 import { renderIdentity } from "../slices/identity/view.js";
 import { renderPayment } from "../slices/payment/view.js";
+import { renderPrimaryProductPrompt } from "../slices/primaryProductPrompt/view.js";
 //#region src/components/HDLKiosk/app/views.ts
 const hdlKioskViews = Object.freeze({
 	identity: renderIdentity,
 	fulfillment: renderFulfillment,
 	customization: renderCustomization,
 	catalog: renderCatalog,
-	catalogWithPrimaryProductPrompt: renderCatalog,
+	primaryProductPrompt: renderPrimaryProductPrompt,
 	paymentMethod: renderPayment,
 	paymentCompleted: renderPayment
 });

package/es/components/HDLKiosk/app/workflow/barcode.js

@@ -1,54 +1,37 @@
 import { defineWorkflow } from "../../kernel/application/defineApplication.js";
-import { catalogWithPrimaryProductPromptSlice } from "../../slices/catalog/slice.js";
+import { catalogSlice } from "../../slices/catalog/slice.js";
 import { customizationSlice } from "../../slices/customization/slice.js";
 import { fulfillmentSlice } from "../../slices/fulfillment/slice.js";
 import { paymentCompletedSlice, paymentMethodSlice } from "../../slices/payment/slice.js";
+import { primaryProductPromptSlice } from "../../slices/primaryProductPrompt/slice.js";
 //#region src/components/HDLKiosk/app/workflow/barcode.ts
 /**
 * 文件角色：声明 Barcode 入口的有序业务步骤。
 * 运行机制：Workflow 从 Catalog 开始；首码在 Session readyForCommands 后由全局 Scanner
-* Controller 消费。Catalog 先询问是否需要麻辣烫，需要时进入 Customization；
-* 最终统一在 Payment 前确认 Fulfillment。
+* Controller 消费。Catalog 完成补充购物后进入独立的主商品询问 Modal，需要时进入
+* Customization；无论选择或拒绝，最终都直接进入 Fulfillment。
 * 边界：设备扫码属于 Session 输入，不是可前进/后退的 Activity；支付 prepare 由支付
 * Operation 在 dispatch 前统一保证，不绑定 Catalog transition。
 */
 const barcodeWorkflow = defineWorkflow({
 	id: "hdl.barcode",
 	steps: [
+		catalogSlice,
 		{
-			slice: catalogWithPrimaryProductPromptSlice,
-			on: {
-				completed: "fulfillment",
-				primaryProductRequested: "customization"
-			}
+			slice: primaryProductPromptSlice,
+			presentation: {
+				mode: "modal",
+				base: "catalog"
+			},
+			visitPolicy: "reuseResolution",
+			on: { skip: "fulfillment" }
 		},
 		{
 			slice: customizationSlice,
-			on: {
-				completed: {
-					target: "catalogWithPrimaryProductPrompt",
-					repeat: {
-						max: 1,
-						exceeded: "blocked"
-					}
-				},
-				skipped: {
-					target: "catalogWithPrimaryProductPrompt",
-					repeat: {
-						max: 1,
-						exceeded: "blocked"
-					}
-				}
-			}
-		},
-		{
-			slice: fulfillmentSlice,
-			on: { back: "catalogWithPrimaryProductPrompt" }
-		},
-		{
-			slice: paymentMethodSlice,
-			on: { eftposSelected: "paymentCompleted" }
+			visitPolicy: "reuseResolution"
 		},
+		fulfillmentSlice,
+		paymentMethodSlice,
 		{
 			slice: paymentCompletedSlice,
 			end: "success"

package/es/components/HDLKiosk/app/workflow/{guards.js → predicates.js}

@@ -1,6 +1,6 @@
 import { _objectSpread2 } from "../../../../_virtual/_@oxc-project_runtime@0.122.0/helpers/objectSpread2.js";
-//#region src/components/HDLKiosk/app/workflow/guards.ts
-const DEFAULT_GUARDS = Object.freeze({
+//#region src/components/HDLKiosk/app/workflow/predicates.ts
+const DEFAULT_PREDICATES = Object.freeze({
 	"cart.notEmpty": ({ sales }) => sales.cart.lineCount > 0,
 	"cart.noPendingMutation": ({ sales }) => !sales.cart.consistencyPending,
 	"identity.satisfied": ({ sales }) => sales.customer !== void 0,
@@ -9,15 +9,15 @@ const DEFAULT_GUARDS = Object.freeze({
 	"payment.notPending": ({ sales }) => sales.payment.status !== "pending" && sales.payment.status !== "unknown",
 	"payment.succeeded": ({ sales }) => sales.payment.status === "succeeded"
 });
-function createGuardRegistry(overrides = {}) {
-	const guards = Object.freeze(_objectSpread2(_objectSpread2({}, DEFAULT_GUARDS), overrides));
-	const ids = Object.freeze(Object.keys(guards));
+function createPredicateRegistry(overrides = {}) {
+	const predicates = Object.freeze(_objectSpread2(_objectSpread2({}, DEFAULT_PREDICATES), overrides));
+	const ids = Object.freeze(Object.keys(predicates));
 	return Object.freeze({
 		ids,
-		has: (id) => Object.prototype.hasOwnProperty.call(guards, id),
-		evaluate: (id, context) => guards[id](context)
+		has: (id) => Object.prototype.hasOwnProperty.call(predicates, id),
+		evaluate: (id, context) => predicates[id](context)
 	});
 }
-const defaultGuardRegistry = createGuardRegistry();
+const defaultPredicateRegistry = createPredicateRegistry();
 //#endregion
-export { defaultGuardRegistry };
+export { defaultPredicateRegistry };

package/es/components/HDLKiosk/app/workflow/quick.js

@@ -8,22 +8,19 @@ import { paymentCompletedSlice, paymentMethodSlice } from "../../slices/payment/
 /**
 * 文件角色：声明 Quick 入口的有序业务步骤。
 * 运行机制：数组顺序就是主路径；这里只保留偏离相邻前进/返回的特殊分支。
-* 边界：Guard、Command、Screen 与失败策略均由本地 Activity Contract 提供。
+* 边界：Predicate、Command、Screen 与失败策略均由本地 Activity Contract 提供。
 */
 const quickOrderWorkflow = defineWorkflow({
 	id: "hdl.quick",
 	steps: [
 		{
 			slice: identitySlice,
-			useGuards: ["beforeEnter"]
+			visitPolicy: "once"
 		},
 		customizationSlice,
 		catalogSlice,
 		fulfillmentSlice,
-		{
-			slice: paymentMethodSlice,
-			on: { eftposSelected: "paymentCompleted" }
-		},
+		paymentMethodSlice,
 		{
 			slice: paymentCompletedSlice,
 			end: "success"

package/es/components/HDLKiosk/app/workflow/registry.js

@@ -7,7 +7,7 @@ const defaultActivityRegistry = Object.freeze({
 	has: (id) => manifestRegistry.has(id),
 	get: (id) => manifestRegistry.has(id) ? manifestRegistry.require(id) : void 0,
 	require: (id) => manifestRegistry.require(id),
-	accepts: (id, outcome) => manifestRegistry.require(id).outcomes.includes(outcome)
+	accepts: (id, intent) => manifestRegistry.require(id).intents.some((availableIntent) => availableIntent === intent)
 });
 const BUILT_IN_WORKFLOW_DEFINITIONS = Object.freeze({
 	quick: normalizeKioskWorkflow(hdlKioskApplication.workflows.quick),

package/es/components/HDLKiosk/app/workflow/scale.js

@@ -14,19 +14,10 @@ import { paymentCompletedSlice, paymentMethodSlice } from "../../slices/payment/
 const scaleWorkflow = defineWorkflow({
 	id: "hdl.scale",
 	steps: [
-		{
-			slice: customizationSlice,
-			on: { skipped: "$next" }
-		},
-		{
-			slice: catalogSlice,
-			on: { back: "customization" }
-		},
+		customizationSlice,
+		catalogSlice,
 		fulfillmentSlice,
-		{
-			slice: paymentMethodSlice,
-			on: { eftposSelected: "paymentCompleted" }
-		},
+		paymentMethodSlice,
 		{
 			slice: paymentCompletedSlice,
 			end: "success"

package/es/components/HDLKiosk/components/shell/HDLKioskBottomBarHost/index.js

@@ -1,5 +1,4 @@
 import { _objectSpread2 } from "../../../../../_virtual/_@oxc-project_runtime@0.122.0/helpers/objectSpread2.js";
-import { _objectWithoutProperties } from "../../../../../_virtual/_@oxc-project_runtime@0.122.0/helpers/objectWithoutProperties.js";
 import { HDLKioskFloatingBar } from "../HDLKioskFloatingBar/index.js";
 import { HDLKioskCartSecondaryActions } from "../HDLKioskCartBarActions/index.js";
 import React, { createContext, useCallback, useContext, useEffect, useLayoutEffect, useMemo, useRef, useState } from "react";
@@ -10,11 +9,6 @@ import React, { createContext, useCallback, useContext, useEffect, useLayoutEffe
 * 并区分 Modal 下可见的 masked 状态与不可导航时的 hidden 状态。
 * 边界：不计算购物车/金额；声明数据必须来自 ViewModel/Projection。
 */
-const _excluded = [
-	"overlayActive",
-	"cartEnabled",
-	"cartOpenBar"
-];
 const HDLKioskBottomBarContext = createContext(null);
 const HDLKioskCartDrawerContext = createContext(null);
 const noop = () => void 0;
@@ -40,6 +34,17 @@ function useHDLKioskBottomBar(declaration) {
 	}, [context, declaration]);
 	useLayoutEffect(() => () => context === null || context === void 0 ? void 0 : context.unregister(owner.current), [context]);
 }
+function toFloatingBarProps(declaration) {
+	const { ariaLabel, className, leading, summary, trailing, variant } = declaration;
+	return {
+		ariaLabel,
+		className,
+		leading,
+		summary,
+		trailing,
+		variant
+	};
+}
 function resolveHDLKioskBottomBarState(mode, screenOverlayActive = false) {
 	const effectiveMode = mode === "hidden" ? "hidden" : mode === "masked" || screenOverlayActive ? "masked" : "visible";
 	return {
@@ -111,10 +116,7 @@ function HDLKioskBottomBarHost({ children, mode = "visible", fallback, cartOverl
 		}),
 		className: `hdl-floating-bar--cart-open${cartBarDeclaration.className ? ` ${cartBarDeclaration.className}` : ""}`
 	}) : renderedDeclaration;
-	const floatingBarDeclaration = activeBarDeclaration ? (() => {
-		const { overlayActive: _overlayActive, cartEnabled: _cartEnabled, cartOpenBar: _cartOpenBar } = activeBarDeclaration;
-		return _objectWithoutProperties(activeBarDeclaration, _excluded);
-	})() : void 0;
+	const floatingBarDeclaration = activeBarDeclaration ? toFloatingBarProps(activeBarDeclaration) : void 0;
 	useEffect(() => {
 		if (presentation.drawerBlocked || !drawerAvailable) setCartOpen(false);
 	}, [drawerAvailable, presentation.drawerBlocked]);

package/es/components/HDLKiosk/components/shell/HDLKioskShell/index.js

@@ -12,6 +12,7 @@ const INLINE_SCREEN_OPERATIONS = new Set([
 	"cart.updateQuantity",
 	"cart.removeLine",
 	"product.syncPrimaryWeightedProduct",
+	"product.removePrimaryProduct",
 	"checkout.requestStaffPaymentApproval",
 	"checkout.payEftpos"
 ]);

package/es/components/HDLKiosk/docs/00-/346/226/207/344/273/266/345/257/274/350/210/252.md

@@ -46,7 +46,7 @@ HDLKiosk/
 | --- | --- |
 | `manifest.ts` | 唯一应用清单；收集 Slice 提供的 Activity/Operation，并绑定三条 Workflow |
 | `constants.ts` | `HDL_WORKFLOW_IDS` 等应用常量 |
-| `events.ts` | HDLKiosk Activity Outcome 的强类型事件联合 |
+| `events.ts` | HDLKiosk Activity Intent 与 Back Navigation 的强类型事件联合 |
 | `operations.ts` | 共享 Operation 的唯一公共导入入口 |
 | `operations/` | `operations.ts` 背后的私有实现、Coordinator 策略和测试；外部代码不要逐文件跨层引用 |
 | `views.ts` | 应用层 Activity → React View 的完整同步注册表；不进入 Slice/Workflow/Kernel |
@@ -54,7 +54,7 @@ HDLKiosk/
 | `workflow/barcode.ts` | Barcode 的有序 Activity 列表与特殊转移 |
 | `workflow/scale.ts` | Scale 的有序 Activity 列表与特殊转移 |
 | `workflow/registry.ts` | 从 Manifest 派生 Activity Registry，并提供内置流程查询 |
-| `workflow/guards.ts` | HDLKiosk 本地 Guard Registry |
+| `workflow/predicates.ts` | HDLKiosk 本地 Predicate Registry |
 | `workflow/policy.ts` | 支付门禁等商家应用策略校验；结构编译仍属于 Kernel |
 | `ScreenRenderer.tsx` | 按当前 Activity 从 `views.ts` 取 View；处理 modal base 叠加和缺失 View 的阻断呈现 |
 | `entry/model.ts` | 派生 Workflow 之外三个入口的可用性和展示模型 |
@@ -75,7 +75,7 @@ slices/<name>/
 └── model.ts         # 仅本 Slice 使用的纯模型；按需存在
 ```
 
-当前 Slice：`identity`、`fulfillment`、`customization`、`catalog`、`paymentMethod`、`paymentCompleted`。`paymentCompleted` 只是支付成功终态，与 `paymentMethod` 共用 Checkout Screen/View，不存在独立 Result Screen。
+当前 Slice：`identity`、`fulfillment`、`customization`、`catalog`、`primaryProductPrompt`、`paymentMethod`、`paymentCompleted`。`primaryProductPrompt` 是以 Catalog 为 base 的 Modal；`paymentCompleted` 是支付成功终态，与 `paymentMethod` 共用 Checkout Screen/View。
 
 - `slices/index.ts` 只汇总各目录导出的 `defineSlice` 结果，并统一约束 `screen.id` 必须是 HDLKiosk `ScreenId`；
 - 每个 `slice.ts` 只通过 `screen: { id }` 声明页面类别；实际 View 在 `app/views.ts` 中按 Activity 单独、完整地注册，使用同步本地组件引用；
@@ -84,7 +84,7 @@ slices/<name>/
 
 `Slice` 是作者侧唯一业务能力概念：`defineSlice` 定义能力，`application.slices` 收集能力，Workflow 的 `slice` 字段引用能力；运行期再编译为 Activity Contract。
 
-命名关系必须保持单向：Slice `id` 是业务 Activity；`screen.id` 是页面类别；`app/views.ts` 按 Activity 注册实际 UI。`catalog` 和 `catalogWithPrimaryProductPrompt` 可以共享 Catalog Screen 与 View，但仍是不同的业务 Slice。非 EFTPOS 店员支付授权是 `paymentMethod` 页面内 Command，不创建 Kiosk 等待 Activity 或弹窗。
+命名关系必须保持单向：Slice `id` 是业务 Activity；`screen.id` 是页面类别；`app/views.ts` 按 Activity 注册实际 UI。`catalog` 负责商品浏览，`primaryProductPrompt` 负责主商品询问，两者通过 Modal base 组合。支付派发和店员支付授权是 `paymentMethod` 页面内 Command，不创建流程 Intent。
 
 ## 5. `components/`：共享展示能力
 
@@ -103,7 +103,7 @@ slices/<name>/
 | `createWorkflowSession.ts` | 读取内置 Definition，直接编译、校验并创建 Actor/Coordinator |
 | `HDLKioskWorkflowView.tsx` | 活跃会话的 React 组合层；连接 Shell、Renderer 和 Controllers |
 | `domainTransitionRunner.ts` | 将 Actor 的 exit effect 交给 Operation Coordinator |
-| `workflowContext.ts` | 只归并经过 Activity Outcome 确认的流程上下文 |
+| `workflowContext.ts` | 只归并经过 Activity Intent 成功提交的流程上下文 |
 | `workflowLifecycle.ts` | Actor blocked/finished 的 Host 遥测与生命周期钩子 |
 | `useHostSnapshot.ts` | 订阅 Host Projection |
 | `useWorkflowSnapshot.ts` | 订阅 Actor Snapshot |
@@ -126,7 +126,7 @@ BigSale 专用 H5 登录实现位于 `bigSale/templates/HDLKiosk/auth/`。独立
 | 位置 | 角色 |
 | --- | --- |
 | `application/` | `defineSlice`、`defineKioskApplication`、Slice 收集和 authoring normalization |
-| `workflow/compiler.ts` | 编译有序 Step 数组，校验 ID、Outcome、可达性、modal base 和有界循环 |
+| `workflow/compiler.ts` | 编译有序 Step 数组，校验 ID、Intent、可达性、modal base 和有界循环 |
 | `workflow/actor.ts` | 单会话串行状态机，拒绝迟到 Activity/Step 事件 |
 | `workflow/transition.ts` | advance/stay/blocked 等转移结果原语 |
 | `operations/coordinator.ts` | 通用排队、去重、timeout、dispose 和 epoch 协调 |
@@ -164,7 +164,7 @@ import {
 - `host.ts`：Host 总入口和 capabilities；
 - `sales.ts`：标准 ProductData、OS 加购流、购物车、客户、履约、支付和 Projection；
 - `devices.ts`：scanner/scale port；
-- `workflow*.ts`：Activity、Definition 和 Guard 协议；
+- `workflow*.ts`：Activity、Definition、Predicate 和 Navigation Guard 协议；
 - `operations.ts`：允许请求的 Operation ID 与输入映射；
 - `results.ts` / `errors.ts` / `telemetry.ts`：结果、错误与观测。
 

package/es/components/HDLKiosk/docs/01-/346/240/270/345/277/203/350/277/220/350/241/214/346/234/272/345/210/266.md

@@ -13,11 +13,11 @@ HDLKiosk Core 不是 BigSale 的另一套页面，也不是本地订单 Store。
                   ↓
 Runtime Controller 决定是否启动会话或消费设备事件
                   ↓
-Screen 内部动作走 Command；离开步骤才产生 Activity Outcome
+Screen 内部动作走 Command；离开步骤产生 Activity Intent，返回产生 Navigation
                   ↓
-Workflow Actor 根据 Outcome 选择静态 Transition并管理串行状态
+Workflow Actor 根据 Intent 选择静态 Transition，并按页面历史处理 Back Navigation
                   ↓
-HDLKiosk Transition Runner 执行本地 Guard / Exit Command并解释交易结果
+HDLKiosk Transition Runner 求值本地 Predicate、执行 Exit Command 并解释交易结果
                   ↓
 Operation Coordinator 安全执行 Screen Command 或 Exit Command
                   ↓
@@ -36,7 +36,7 @@ Screen Renderer 根据当前节点与最新 Projection 渲染
 | 流程状态 | entry、nodeId、fulfillment 本地选择、session epoch | Workflow Runtime | 只回答“顾客处于哪一步”，不能证明订单已写成功 |
 | 展示输入 | options 选中项、搜索词、Modal 内选择               | Screen           | 可以随页面销毁，不得成为结账依据             |
 
-核心规则是“流程、命令与事实分离”：Screen Command/Exit Command 发起业务写入；writer receipt 证明本次写入完成了什么；Projection 提供当前 UI 可观察事实；Workflow Definition 只描述 Activity Outcome 到目标节点的关系。
+核心规则是“流程、命令与事实分离”：Screen Command/Exit Command 发起业务写入；writer receipt 证明本次写入完成了什么；Projection 提供当前 UI 可观察事实；Workflow Definition 只描述 Activity Intent 到目标节点的关系，Back Navigation 不写入 Definition。
 
 ## 2. 目录与运行时角色
 
@@ -49,10 +49,10 @@ Screen Renderer 根据当前节点与最新 Projection 渲染
 | [`app/workflow/`](../app/workflow)                                          | 三入口业务编排与本地策略    | Activity 数组与特殊分支                         | Quick/Barcode/Scale Definition                  | 流程顺序集中在应用目录，不和 Slice 实现混杂               |
 | [`runtime/createWorkflowSession.ts`](../runtime/createWorkflowSession.ts)     | 一次点餐会话的组合根        | entry、Host、locale、可选 Lifecycle 扩展      | Kernel 与 HDLKiosk 业务实现的稳定组合           | 避免页面各自创建状态机或副作用执行器                    |
 | [`app/workflow/registry.ts`](../app/workflow/registry.ts)                    | Activity Registry 类型视图  | Application Manifest                         | 带 HDLKiosk 字面量类型的 Registry                | Runtime 不再维护第二份 Activity 清单                    |
-| [`kernel/workflow/compiler.ts`](../kernel/workflow/compiler.ts)              | Definition 结构校验         | Workflow Definition + 注入的 Registry        | 冻结后的可执行 Definition 或 issues            | 防止未知 Outcome、非法跳转和无界循环进入 Actor          |
+| [`kernel/workflow/compiler.ts`](../kernel/workflow/compiler.ts)              | Definition 结构校验         | Workflow Definition + 注入的 Registry        | 冻结后的可执行 Definition 或 issues            | 防止未知 Intent、非法跳转和无界循环进入 Actor           |
 | [`app/workflow/policy.ts`](../app/workflow/policy.ts)                        | HDLKiosk 业务策略校验       | 编译后的 Definition                          | 支付门禁等业务 issues                          | 结构规则不与具体交易策略混在一起                        |
-| [`kernel/workflow/actor.ts`](../kernel/workflow/actor.ts)                     | 单会话流程执行器            | Activity Outcome、Definition、Runner         | WorkflowSnapshot、Transition                   | 解决双击、乱序导航和 Exit Command 完成前跳页            |
-| [`runtime/domainTransitionRunner.ts`](../runtime/domainTransitionRunner.ts)   | Activity 离开策略执行器     | Exit Policy、Host Projection、Coordinator    | advance/stay/blocked、支付回执                 | Actor 不理解 Guard、购物车和支付 Operation              |
+| [`kernel/workflow/actor.ts`](../kernel/workflow/actor.ts)                     | 单会话流程执行器            | Activity Intent、Navigation、Definition、Runner | WorkflowSnapshot、Transition                 | 解决双击、乱序导航和 Exit Command 完成前跳页            |
+| [`runtime/domainTransitionRunner.ts`](../runtime/domainTransitionRunner.ts)   | Activity 离开策略执行器     | Exit Policy、Host Projection、Coordinator    | advance/stay/blocked、支付回执                 | Actor 不理解 Predicate、购物车和支付 Operation          |
 | [`runtime/workflowLifecycle.ts`](../runtime/workflowLifecycle.ts)             | 已提交状态的业务生命周期出口 | Actor 提交后的 Snapshot                     | telemetry                                      | 诊断不进入状态机内核                                    |
 | [`kernel/operations/coordinator.ts`](../kernel/operations/coordinator.ts)     | 通用副作用调度器            | Operation request + 应用 Policy              | 规范化 OperationResult                         | 解决重复 intent、排队、超时和旧 Promise；不认识支付     |
 | [`app/operations.ts`](../app/operations.ts)                                  | 共享 Operation 公共入口     | 跨 Slice Operation 与执行策略                | 稳定的统一导出面                               | 避免消费者穿透私有实现目录                              |
@@ -172,34 +172,41 @@ Workflow 用有序 Slice 数组描述静态编排。数组顺序是默认主路
 {
   id: 'hdl.barcode',
   steps: [
+    catalogSlice,
     {
-      slice: catalogWithPrimaryProductPromptSlice,
-      on: { completed: 'paymentMethod' },
+      slice: primaryProductPromptSlice,
+      presentation: { mode: 'modal', base: 'catalog' },
+      on: { complete: 'customization', skip: 'fulfillment' },
     },
-    { slice: customizationSlice, on: { completed: 'catalogWithPrimaryProductPrompt' } },
-    { slice: paymentMethodSlice, on: { back: 'catalogWithPrimaryProductPrompt' } },
-    // ...
+    {
+      slice: customizationSlice,
+      on: { complete: 'fulfillment', skip: 'fulfillment' },
+    },
+    fulfillmentSlice,
+    paymentMethodSlice,
     { slice: paymentCompletedSlice, end: 'success' },
   ],
 }
 ```
 
-Workflow 作者不会填写 Screen、Guard、Operation 或 failureTarget；这些由 Slice 引用带入本地可信 Manifest。Compiler 使用的规范化结构只保留 Activity ID、presentation 与目标，不携带 React 组件、Host 方法或订单对象。Quick、Barcode、Scale 的差异只保留在 [`app/workflow/`](../app/workflow)。
+Workflow 作者不会填写 Screen、Predicate、Operation 或 failureTarget；这些由 Slice 引用带入本地可信 Manifest。Compiler 使用的规范化结构只保留 Activity ID、presentation 与目标，不携带 React 组件、Host 方法或订单对象。Quick、Barcode、Scale 的差异只保留在 [`app/workflow/`](../app/workflow)。
 
 四个概念必须分开：
 
-- **Slice**：开发者定义的完整业务能力，包含 Screen、Outcome、Command 和退出 Effect；
+- **Slice**：开发者定义的完整业务能力，包含 Screen、Intent、Command 和退出 Effect；
 - **Activity**：Slice 暴露给 Actor 的无 UI 运行契约，例如 `catalog`；
 - **Step**：Activity 在一条流程中的一次出现，是编排和运行时定位的稳定位置；
 - **Screen**：Activity 的本地 UI 实现，不属于 Workflow Definition。
 
 Slice 在一条流程只出现一次时，Step ID 默认就是 Slice ID；同一 Slice 多次出现时，每次必须显式使用 `slice:用途`，例如 `catalog:initial`、`catalog:final`。这样既保持常规流程易读，也不会把复用能力误认为同一个运行位置。
 
-Slice Outcome 使用 `next()` / `back()`，或在 `guard/effect` 上声明 `navigate`，决定相邻 Step 的默认移动。不会移动的 Outcome 只在 Workflow `on` 中指定特殊目标。没有下一项的 Step 不会被推测为成功，必须声明 `end: 'success' | 'blocked'`。
+Slice Intent 使用 `next()`，或在 `intentPrecondition/effect` 上声明 `navigate: 'next'`，决定相邻 Step 的默认移动。不会自动前进的 Intent 只在 Workflow `on` 中指定目标。Back 是独立 Navigation，由 Actor 的实际页面历史解析。没有下一项的 Step 不会被推测为成功，必须声明 `end: 'success' | 'blocked'`。
+
+Predicate 是本地可信的纯真假判断，例如 `cart.notEmpty`；Intent Precondition 表示某个 Intent 提交前必须满足的 Predicate。作者 API 使用 `intentPrecondition(predicateId)`，底层行为记录 `{ kind: 'precondition', predicate }`，编译后存入 `exitPolicy.precondition`。Predicate 只返回 boolean；它与能返回 `allow | bypass | cancel | redirect | defer | block` 的 Navigation Guard 是两套独立能力。
 
-条件式步骤在 Slice `guards` 中声明本地纯函数，Workflow occurrence 使用 `{ slice: identitySlice, useGuards: ['beforeEnter'] }` 选择启用阶段。Application 为函数生成稳定 Guard ID；编译后 Node 只保留 `guardPhases` 数组，不保留函数或 Guard ID。Actor 的全局 `beforeEach` 管线在初始进入、前进、后退和显式目标跳转时都接收 `to` / `from` / `direction`。守卫返回结构化决策 `allow | skip | cancel | redirect | defer | block`；`skip` 才会按当前方向继续解析，不再用含义模糊的 boolean。Kernel 不读取 Identity、Fulfillment 等业务名称。
+业务 Workflow 当前不启用 Slice `beforeEnter` 守卫。Actor 仍保留全局 `beforeEach` 管线，用于 `sessionExit` 等会话安全策略；它不承载 Identity、Fulfillment 等步骤的业务进入条件。
 
-Actor 记录的是已成功向前离开的 **Step ID**，而不是 Slice ID。因此同一 Slice 可在 Flow 中出现多次，每个 occurrence 都可独立声明 `useGuards`；第一个被守卫跳过，不会影响第二个未启用守卫的 Step。导航在执行 Activity Exit Effect 之前完成解析；被 cancel/defer 的导航不会先写 Host。
+Actor 分别记录已成功向前离开的 Step、每个 Step 已提交的 `complete | skip` Resolution，以及用户实际访问过的页面历史。`back` 按实际页面历史返回，Modal 和 Skip Step 不写入历史；历史为空时 Back 进入会话退出导航。Workflow occurrence 通过 `visitPolicy: 'always' | 'reuseResolution' | 'once'` 明确声明再次访问策略：`always` 重新展示，`reuseResolution` 再次向前时复用已提交 Resolution，`once` 提交后不再进入且不写入 Back 历史。用户通过 Back 退出一个已解决页面时，其旧 Resolution 失效。导航在执行 Activity Exit Effect 之前完成解析；被 cancel/defer 的导航不会先写 Host。
 
 退出流程也是导航目标 `{ kind: 'sessionExit' }`。全局 `beforeEach` 对它返回 `defer({ kind: 'confirmEndOrder' })`，Actor 保存带唯一 `navigationId` 的 `pendingNavigation`。Shell 只根据该 request 展示确认；旧 ID 不能恢复后来的导航。
 
@@ -210,30 +217,30 @@ Step ID 只标识“一次出现”。Runtime 判断加载哪类数据、是否
 [`slices/<name>/slice.ts`](../slices) 是本地可信 Slice 定义，每个 Slice 声明：
 
 - 业务 Activity 使用哪个 `screen.id`，以及该 Screen 的 `view`；
-- 可以产生哪些 Outcome；
+- 可以接受哪些 Intent；
 - 支持 page 还是 modal；
-- 某个 Outcome 是否需要纯 Guard；
+- 某个 Intent 是否需要纯 Predicate 作为 Precondition；
 - 离开 Slice 前是否需要执行 Effect；
 - Screen 内有哪些不会离开节点的 Command；
 - 使用该 Slice 的流程在支付前需要哪些业务事实。
 
-例如 `identity.skipped` 的本地 Exit Policy 执行 `identity.sync`，`customization.completed` 检查 `customization.primaryReady`，`paymentMethod.cardSelected` 执行 `checkout.open`。`defineKioskApplication` 从 Slice 自动生成 Activity Contract 与 Operation 注册信息；未来后台只会看到 `Slice ID + Outcome → target`，不能替换这些安全规则。
+例如 `identity.complete` / `identity.skip` 可在携带输入时执行 `identity.sync`，`customization.complete` 执行主商品同步，`paymentMethod.complete` 检查 Host 已确认支付成功。EFTPOS 派发和店员支付授权是 Payment 页面 Command，不作为流程 Intent。`defineKioskApplication` 从 Slice 自动生成 Activity Contract 与 Operation 注册信息；远端定义只看到 `Slice ID + 标准 Intent → target`，不能替换这些安全规则。
 
 Slice 的业务定义与 React View 分离：Slice `id` 是 Workflow 和 Actor 使用的业务 Activity；`screen.id` 会被 Compiler 复制为 Workflow Node 的 `screenId`，供 Shell、Controller 和数据加载策略使用；`app/views.ts` 按 Activity 注册本地可信 View。各 Slice 的 `view.tsx` 仍负责 ViewModel 派生与组件装配，但不会进入 `defineSlice` 或 Workflow Definition。
 
 | Slice 定义 | 编译/运行期形态 | 唯一用途 |
 | --- | --- | --- |
-| `id` | Node `activity` | 业务状态、Outcome 和流程编排 |
+| `id` | Node `activity` | 业务状态、Intent 和流程编排 |
 | `screen.id` | Node `screenId` | Shell 变体、数据加载和页面类别判断 |
 | `app/views.ts` 中的 Activity 映射 | 仅应用展示层使用 | React UI 渲染 |
 
-因此 `id`、`screen` 和 `view` 不互相替代：`catalogWithPrimaryProductPrompt` 与 `catalog` 是两个 Slice ID，但共享 `screen.id = 'catalog'` 和同一个 View。店员支付授权不改变当前页面，因此是 `paymentMethod` 的 Screen Command，而不是独立 Activity。Application Manifest 是业务运行 Contract 的唯一索引，`app/views.ts` 是展示实现的唯一索引。View 使用同步本地组件引用，不产生运行期 UI chunk；纯 Compiler/Actor 依赖链也不会加载该注册表。Renderer 若发现 View 缺失，仍使用 `BlockingNotice` fail closed，且不会改变 Workflow。
+因此 `id`、`screen` 和 `view` 不互相替代：`catalog` 是商品浏览页面，`primaryProductPrompt` 是覆盖在 Catalog 上的独立 Modal Slice。店员支付授权不改变当前页面，因此是 `paymentMethod` 的 Screen Command，而不是独立 Activity。Application Manifest 是业务运行 Contract 的唯一索引，`app/views.ts` 是展示实现的唯一索引。View 使用同步本地组件引用，不产生运行期 UI chunk；纯 Compiler/Actor 依赖链也不会加载该注册表。Renderer 若发现 View 缺失，仍使用 `BlockingNotice` fail closed，且不会改变 Workflow。
 
 `slices/index.ts` 对整套 Slice 清单执行一次类型约束：`screen.id` 只能取 HDLKiosk 的非 Entry `ScreenId`。`app/views.ts` 使用完整的 `Record<ActivityId, HDLKioskSliceView>`，因此新增 Activity 若没有注册 View 会产生类型错误。Kernel 的 `defineSlice` 同时拒绝空 `screen.id`。
 
 Compiler 从实际使用的 Slice 汇总 Checkout Requirement ID，但不把判断函数或 Host 字段写入 Workflow。当前 HDLKiosk 默认注册表为空；未来增加其他业务要求时仍由 [`checkoutRequirements.ts`](../app/operations/checkoutRequirements.ts) 集中判断。
 
-`WorkflowEvent` 同时约束 Activity、Outcome 和必要输入：例如 `identity.skipped` 必须携带身份输入，`fulfillment.completed` 必须携带 fulfillment context patch。Barcode 入口的条码输入不是 Workflow Event，而是 Session Controller 在发布会话前交给 `barcode.consume` 的 Command 输入。Screen Command 由 `OperationInputMap` 约束 Command ID 与输入类型，不再通过 `unknown` 保持隐式默契。
+`WorkflowEvent` 同时约束 Activity、Intent 和必要输入：例如 `identity.skip` 必须携带身份输入，`fulfillment.complete` 必须携带 fulfillment context patch。Back 使用不携带业务输入的 `NAVIGATE_BACK`。Barcode 入口的条码输入不是 Workflow Event，而是 Session Controller 在发布会话前交给 `barcode.consume` 的 Command 输入。Screen Command 由 `OperationInputMap` 约束 Command ID 与输入类型。
 
 Step 可选声明 Modal 展示关系：
 
@@ -249,7 +256,7 @@ presentation: { mode: 'modal', base: 'customization' }
 
 - workflow id、Step 数组及数量/transition 上限；
 - Activity 是否存在；重复 Activity 是否具有稳定且不冲突的 Step ID；
-- Outcome 是否由 Activity Contract 暴露；
+- Intent 是否由 Activity Contract 暴露；
 - Definition 是否夹带 screen/guard/operation/failureTarget；
 - 默认相邻导航和显式 target 是否有效，所有 Step 是否从首项可达；
 - 无后继 Step 是否声明结束语义，首项是否能到达成功终点；
@@ -264,16 +271,16 @@ session 创建前完成，但结构错误与业务安全错误保持独立。
 
 数组天然只有一个首项；不可达 Step 会被拒绝。显式业务回路必须声明 `repeat.max`，Actor 按会话计数，超过限制进入阻塞态。普通 Back 属于用户导航，不计入业务回路限制。校验通过后，Compiler 把数组转成 Actor 查询高效的冻结节点 Map；运行中的 session 不替换 Definition。
 
-### 6.4 Actor 如何处理 Activity Outcome
+### 6.4 Actor 如何处理 Activity Intent 与 Navigation
 
 Actor 使用单 mailbox：
 
 1. 忽略 success end、blocked 或 disposed 后的新事件；
 2. 同时校验事件的 `stepId` 和 `activityId`，拒绝旧 Screen 或同类 Activity 旧实例的迟到回调；
-3. 校验 Outcome 是否由当前 Activity 暴露，并查找 Transition；
+3. 校验 Intent 是否由当前 Activity 暴露，并查找 Transition；Back 则读取页面历史；
 4. 通过注入的 Context Reducer 合并受限 contextPatch；
 5. 把 Exit Policy 交给 HDLKiosk Transition Runner；
-6. Runner 用最新 Sales Projection 执行 Guard，并通过 Coordinator 执行 Exit Command；
+6. Runner 用最新 Sales Projection 求值 Precondition Predicate，并通过 Coordinator 执行 Exit Command；
 7. Runner 将结果归一为 `advance / stay / blocked`，支付成功回执也由 Runner 解释；
 8. Actor 只负责提交 target、当前 Step 或 blocked，并清理 active operation；
 9. 已提交 Snapshot 交给 Workflow Lifecycle 记录 telemetry；外层可组合额外观察器。
@@ -301,7 +308,7 @@ Coordinator 现在有两个明确调用来源：
 - Screen Command：Catalog 加购、Cart Overlay 数量修改、称重草稿同步等；由 `session.executeCommand` 执行，成功后 Actor 节点不变；
 - Activity Exit Command：Guest 同步、Checkout Prepare/Open 等；由 Transition Runner 从本地 Exit Policy 发起，只有 succeeded 才允许 Actor 转移。
 
-partialFailure/unknown 的 Screen Command 会通过 Actor 的 system block 入口 fail closed；它不是伪造一个 Activity Outcome。
+partialFailure/unknown 的 Screen Command 会通过 Actor 的 system block 入口 fail closed；它不伪造 Activity Intent。
 
 当前 Operation 组：
 
@@ -313,6 +320,7 @@ partialFailure/unknown 的 Screen Command 会通过 Actor 的 system block 入
 | `cart.addProduct`                    | cart     | —       | 调宿主商品 Flow，等待规格或其它业务选择后验证写入                                      |
 | `cart.update/remove`                 | cart     | 15s     | 数量修改/删除、summary 重算和目标行验证                                                |
 | `product.syncPrimaryWeightedProduct` | cart     | —       | 首次写入可能等待 OS 额外业务弹窗；更新或写入后验证重量/options 和写后证据              |
+| `product.removePrimaryProduct`       | cart     | 15s     | 将主商品置为不存在；本来不存在时直接成功，存在时验证删除结果                |
 | `checkout.prepare*`                  | checkout | 20s     | fulfillment、cart、summary 稳定性与 token                                      |
 | `checkout.open`                      | checkout | 120s    | 消费 token、冻结危险写并打开 Host 支付                                                 |
 
@@ -389,22 +397,22 @@ Host command
 - 尚无活跃或启动中的 session；
 - 支付状态未冻结。
 
-通过 ScannerIngress/ScaleIngress 完成 eventId 去重、阈值检查和拒绝原因遥测。Device Controller 不向 Actor 发送 `detected` Outcome；Barcode 把条码作为 start request 的一部分，Scale 只发起 Scale session。
+通过 ScannerIngress/ScaleIngress 完成 eventId 去重、阈值检查和拒绝原因遥测。Device Controller 不向 Actor 发送流程 Intent；Barcode 把条码作为 start request 的一部分，Scale 只发起 Scale session。
 
 ### 8.3 Customer Controller
 
-Identity 节点内的登录是 Activity Outcome，不是 Screen 直接写订单：
+Identity 节点内的登录是 Activity Intent，不是 Screen 直接写订单：
 
 ```text
 BigSale Login2/Register2
 → 暂存已认证 customer
-→ identity.memberRecognized(customerId)
+→ identity.complete(customerId)
 → identity.sync Exit Effect
 → Adapter customer.select + consistency + repricing
 → 成功后进入下一节点
 ```
 
-认证 UI 通过 HDLKiosk 应用展示层插槽注入，不进入 `defineSlice`、View 注册表或 Kernel。Slice 只声明 `memberRecognized` 在携带输入时执行 `identity.sync`；已登录客户的自动略过不携带输入，因此不会重复写客户。
+认证 UI 通过 HDLKiosk 应用展示层插槽注入，不进入 `defineSlice`、View 注册表或 Kernel。Slice 的 `complete` 在携带输入时执行 `identity.sync`；已登录客户的自动略过使用 `skip` 且不携带输入，因此不会重复写客户。
 
 Shell 登录不是 Workflow 跳转，而是 session-level 插入 Operation：
 
@@ -475,8 +483,9 @@ HDLKiosk root
 → components/shell + components/overlays + components/common
 → Activity Action callback
 → HDLKioskWorkflowView
-├─ Outcome → Workflow Actor
-│             → HDLKiosk Transition Runner（Guard / Exit Command）
+├─ Intent → Workflow Actor
+├─ Back → Workflow Navigation
+│             → HDLKiosk Transition Runner（Predicate / Exit Command）
 ├─ Command → session.executeCommand → Coordinator
 └─ Session Action → reset controller
 ```
@@ -499,7 +508,7 @@ Screen 只做三件事：
 
 1. 渲染 View DTO；
 2. 维护局部输入；
-3. 内部业务写入发送 Screen Command，离开步骤发送 Activity Outcome。
+3. 内部业务写入发送 Screen Command，离开步骤发送 Activity Intent，返回发送 Navigation。
 
 Screen 不得：
 
@@ -515,13 +524,13 @@ CartDrawer 也遵循“Screen 声明、Shell 挂载”：Screen 只请求打开
 
 Customization 的规格 UI 通过 `components/common/HDLKioskSkuOptionsSelection` 接入共享 `skuOptionsSelection`。查询所得 ProductData 本身直接作为 `dataSource`，兼容层不再复制或重命名 option group/item，只在选择器 `SkuValue` 与业务命令所需 `HDLProductOptionSelection[]` 之间转换“用户选中结果”。临时独立运行缺少 Engine 上下文时，退化为直接读取同一 `option_group/option_item` 的单选控件。
 
-称重主商品在 Customization 中先保持页面本地草稿。重量或 options 变化不写 Host；点击 Next 时才将当下完整草稿作为 `customization.completed` 的 Exit Effect 交给 `product.syncPrimaryWeightedProduct`。OS 完成其内部业务判断并返回加购成功，且 writer receipt/Projection 验证通过后，Actor 才进入下一节点。失败或取消留在当前页面，`partial/unknown` 阻断。底栏和 Drawer 仍只消费 Host `summary.due/cart.lines`，不在本地构造未确认的购物车。
+称重主商品在 Customization 中先保持页面本地草稿。重量或 options 变化不写 Host；点击 Next 时才将当下完整草稿作为 `customization.complete` 的 Exit Effect 交给 `product.syncPrimaryWeightedProduct`。OS 完成其内部业务判断并返回加购成功，且 writer receipt/Projection 验证通过后，Actor 才进入下一节点。失败或取消留在当前页面，`partial/unknown` 阻断。底栏和 Drawer 仍只消费 Host `summary.due/cart.lines`，不在本地构造未确认的购物车。
 
 Workflow View 负责控制器组合、自动推进和会话级 Dialog；Renderer 只负责选择要展示的组件。普通 `cart.add/update/remove` 和防抖的 `product.syncPrimaryWeightedProduct` 是 Screen Command，保持当前 Activity 挂载，只禁用冲突操作，不产生 transition；会员重报价和 Checkout 等 Activity Exit Command 才阻断整个 surface。
 
 OS 加购过程中的内部弹窗和业务判断不属于 HDLKiosk Activity、Host Contract 或 Checkout Requirement。HDLKiosk 不读写相关业务事实，只根据主商品加购操作的最终结果决定是否跳转。
 
-Barcode 的主商品询问采用相同原则，但它属于 `catalogWithPrimaryProductPrompt` Activity 的局部 Dialog：No 产生 `completed`，Yes 产生 `primaryProductRequested`。是否打开 Dialog 只由当前购物车是否包含主商品决定，不形成 `primaryProductPrompt` Workflow 节点。
+Barcode 的主商品询问是独立 `primaryProductPrompt` Modal Slice：Yes 发出 `complete`，No 发出 `skip`。Actor 成功提交后直接记录同名 Resolution。Prompt 和 Customization occurrence 均声明 `visitPolicy: 'reuseResolution'`，因此拒绝或跳过后，从 Fulfillment 返回 Catalog 再次前进不会重复展示它们。正常完成 Customization 后可从 Fulfillment Back 返回编辑；若再退回 Catalog，旧 Customization Resolution 失效，之后前进会重新展示。跳过已有主商品前会先通过本地 Exit Effect 删除对应购物车行。
 
 ## 11. 四条端到端调用链
 

package/es/components/HDLKiosk/docs/03-/344/270/232/345/212/241/346/265/201/347/250/213/344/270/216/344/272/244/344/272/222/350/247/204/345/210/231.md

@@ -26,7 +26,7 @@ Entry → Identity → Customization → Catalog → Fulfillment
       → Payment Method / Payment Completed → Entry
 ```
 
-- Identity Slice 在 `guards.beforeEnter` 中声明进入条件，Quick 只在该 occurrence 配置 `useGuards: ['beforeEnter']`。本 Step 登录或 Skip 成功后守卫返回 `skip`，因此后退会跳过它。Fulfillment Back 因没有更早的可进入 Step，导航目标变为 `sessionExit`；全局守卫返回 `defer(confirmEndOrder)` 并打开结束订单确认。确认后返回 Entry，取消则留在当前页。
+- Quick 的 Identity occurrence 显式声明 `visitPolicy: 'once'`。登录或 Skip 成功后，该 Step 在本会话不再进入，也不写入 Back 页面历史。当没有更早的已访问页面时，Back 的导航目标为 `sessionExit`；全局会话策略返回 `defer(confirmEndOrder)` 并打开结束订单确认。确认后返回 Entry，取消则留在当前页。
 - Fulfillment 统一位于 Payment 之前确认堂食/外带。
 - Customization 只在稳定正净重且必选 options 完整时启用 Next。
 - “I don't need Malatang” 直接跳过主商品并进入 Catalog；如果正在编辑已确认主商品，则先移除该行。
@@ -76,6 +76,6 @@ Identity 的 Skip 只表示当前以 Guest 继续。Shell 可在本地策略允
 - 尺寸校准以上线环境的实际渲染值反推：当 72px 在目标倍率下实测为 100px，而原型目标为 108px 时，当前自有视觉值统一乘以 `108 / 100 = 1.08`；外部生产组件不参与这一次修正。
 - Screen 不得直接 import BigSale/SalesSDK，也不本地计算最终金额。
 - Screen 内部写操作使用 Screen Command；离开节点的写操作使用 Activity Exit Effect。
-- `product.syncPrimaryWeightedProduct` 属于 Customization `completed` 的 Exit Effect，不是输入变化时的 Screen Command。
+- `product.syncPrimaryWeightedProduct` 属于 Customization `complete` 的 Exit Effect，不是输入变化时的 Screen Command。
 - Shell 的购物车、金额和 Drawer 只消费 Host 已确认 Projection。
 - 调整节点顺序时同步更新 Workflow Definition、compiler/definition/actor/Screen 测试和实施进度。

package/es/components/HDLKiosk/docs/05-/344/272/244/346/230/223/345/256/211/345/205/250.md

@@ -31,7 +31,7 @@ Host 无法证明写后事实时，Operation 不能返回 succeeded。Cart 和 C
 
 ## 3. Checkout Prepared Freshness
 
-Prepare 不是某个页面之前或某个 Workflow outcome 的固定副作用。Checkout Coordinator 把它作为所有支付 dispatch 的前置条件，对当前事实版本执行 `ensurePrepared(currentVersion)`。
+Prepare 不是某个页面之前或某个 Workflow Intent 的固定副作用。Checkout Coordinator 把它作为所有支付 dispatch 的前置条件，对当前事实版本执行 `ensurePrepared(currentVersion)`。
 
 事实版本至少包括 session epoch、cart fingerprint、customer/voucher/promotion revision、Summary 应付金额/币种、Requirement 集合和支付能力上下文。状态为：
 

package/es/components/HDLKiosk/docs/07-/345/220/216/347/273/255/345/267/245/344/275/234.md

@@ -35,7 +35,7 @@
 ### P1-1 商品和 Catalog
 
 - 将模板内临时固定商品 ID 改为租户/门店正式称重商品配置；商品结构已经切换为 OS `queryProducts`，不得恢复本地 fallback；
-- 确认 Quick 是否允许跳过称重主商品；若不允许，从 `customization` Activity Contract/Workflow 中删除 `skipped` Outcome；
+- 确认 Quick 是否允许跳过称重主商品；若不允许，从 `customization` Activity Contract/Workflow 中移除 `skip` Intent；
 - 大目录分页/虚拟滚动与分类切换性能；分类、子分类和本地搜索首版已完成；
 - 缺货、下架、菜单不可用、价格变化；
 - Barcode 细分 added/requiresSelection/notFound/cancelled；