POS 与零售运营技能定义一套可审计的收银操作契约：让销售录入快速，同时把客户、商品、库存、支付、权限和会计决策显式化、可重复。
一、用途 该技能在构建或审查多租户零售 POS、外勤代理 POS 或手工销售补录界面时使用；也用于定义默认客户行为、商品选择、库存校验、收款捕获，以及商品与成品库存之间的关系；还可用于审计不同销售入口是否写入同一权威事务边界并产生一致的库存与会计结果，以及设计低摩擦的柜台流程。
二、主要能力
- 区分三类操作界面：pos.php（门店或租户 POS）、agent-pos.php（严格代表销售代理过账）、encode-sales.php（补录已发生的销售）。三者可共享展示组件与过账服务，但不得静默互换。批量报价、订单受理、交付、开票与收款属于独立的订单到收款流程，不归本技能。
- 显式解析租户默认客户：每个租户配置一个通用默认客户（通常名称为“Walk-in”），由租户/加盟设置选择，超级管理员、最高管理员及获专门配置权限的租户用户可修改。三个界面加载时都必须解析同一服务端设置，不得按名称含“cash”“walk”搜索或取第一个活跃客户。配置缺失或停用是可见的配置状态，不得猜测。操作员可在过账前换成具名客户，默认值只是初始状态。
- 区分商品与库存标识：操作员销售商品，每个可售商品有一一对应的成品库存项。商品承载客户可见的名称、图片、分类、价格与描述；库存项承载库存标识、计量单位、批次、成本与余额。界面不得把原料、包装或任意原料库存项当作可售商品。制造消耗配方原料并产出映射的成品；销售商品扣减其映射的成品，而非配方原料。可用量、FEFO/批次选择、成本核算与分类账必须在服务边界使用该映射。
- 设计操作循环：识别操作员上下文 → 确认客户 → 查找商品 → 显示价格与可用数量 → 添加或编辑数量 → 选择支付方式或赊账 → 复核合计 → 一次过账 → 显示收据/参考号。当前分店/门店/代理上下文需可见；商品名与成品可用量比内部编码更突出；购物车可编辑、合计稳定、错误附着于受影响行；重试时沿用服务端生成的幂等键，不得因支付弹窗或网络慢而重复建单。
- 权威事务边界：三个界面调用同一过账服务或显式适配器，事务需原子校验租户、权限、客户、商品映射、批次/库存可用量、价格、发票、支付、库存扣减、总账过账与审计链路。界面“成功”状态不算证据，需核对持久化的发票、支付、库存分类账与日记账。
- 视觉系统：采用克制、高对比的运营层级，一个明确主操作、常驻购物车摘要、可见上下文与简短恢复文案；选择明确的字体搭配并测试数字可读性；用颜色表示状态并以文字或图标作冗余提示；遵循设计准则、WCAG 2.2 与宿主产品令牌。
三、使用方式 先阅读架构、服务、路由、权限与代表性界面，再修改 POS 契约；使用服务端推导的租户上下文与预处理语句，不信任浏览器传来的租户、分店、门店或客户 ID；仅在明确授权下编辑，设计评审保持只读；用 PHP lint、JavaScript 语法检查、针对性契约测试及数据库支撑的应用/回滚或试运行/验证路径进行验证。
四、适用场景与限制 适用于计数器快速录入、代理销售、销售补录及多销售入口一致性审计。不适用于消费者发现、在线结账、配送跟踪或退货（应使用电商结账 UX）、通用表单/表格/弹窗设计、财务报表或会计控制设计；批量报价到收款应作为订单到收款流程单独定义。
五、降级模式 浏览器或数据库不可用时，提供界面/服务契约并标记交互、持久化与无障碍检查未验证；商品到库存映射不完整时不得编造映射，应返回缺陷登记并阻止受影响商品发布；支付或总账夹具不可用时仅验证请求形状与幂等路径，并明确阻止生产签核。