feat: add party-size queueing and call modes

docs/scenic-queue-system-plan.md

@@ -1,7 +1,7 @@
 # 景区项目排队叫号系统：案例调研与完整规划
 
-> 文档状态：v1.0 已确认开发基线  
-> 调研日期：2026-07-10  
+> 文档状态：v1.1 已确认开发基线
+> 调研日期：2026-07-10；人数与双叫号模式修订：2026-07-15
 > 当前阶段：关键产品与技术决策已确认，已获授权进入开发。  
 > 适用前提：绿地项目；一个景区内存在多个游玩项目，每个项目可能有多个通道、设备或服务批次。
 
@@ -13,30 +13,30 @@
 
 核心方案是：
 
-1. 取号采用“一人一号”：每位游客对应一张 `QueueTicket`，不建立同行组或 `party_size` 规则。手机号必填，姓氏和称谓选填；称谓未填写时默认为“游客”，系统不采集法定性别。每次取号生成不可猜测的排队单 ID、可读票号和私密查询令牌。
+1. 每张 `QueueTicket` 对应一个排队号码，并保存创建后不可修改的同行人数 `party_size`。手机号和同行人数必填，姓氏和称谓选填；人数必须落在项目配置的连续范围内。每次取号生成不可猜测的排队单 ID、可读票号和私密查询令牌。
 2. 同一手机号在同一项目可同时持有多个活动号码，以支持家人共用联系人手机号。发现重复时员工端必须展示脱敏的活动号码提示，经员工明确确认后方可继续，并记录审计；数据库不得设置“项目 + 手机号”的活动唯一约束。
-3. “批量叫号”建模为独立 `CallBatch`。每个项目配置固定人数 `N`，`CALL_NEXT` 严格按 FIFO 原子呼叫队首连续 `N` 个有效等待号码；不足 `N` 时呼叫全部剩余号码，不手选、不跳号。
-4. 预计等待时间只配置“单个号码预计间隔时间”，每个号码按该间隔累加计算；界面显示易懂的预计时间和更新时间，不建设通用预测平台。
+3. “批量叫号”建模为独立 `CallBatch`。项目可支持按号码、按人数或两种方式；两种方式均严格 FIFO、连续、不手选、不跳号。按人数时选择合计人数不超过目标的最长队首前缀，不拆分号码。
+4. 预计等待时间只配置“单人预计间隔时间”，按本号前方所有号码的实际人数累加，不包含本号自身同行人数；界面显示易懂的预计时间和更新时间，不建设通用预测平台。
 5. PostgreSQL 是唯一事实源，中心服务是唯一写入权威。景区完全断外网或客户端无法确认中心权威时，停止数字化取号与叫号，只展示最后快照并切换纸质号码、人工广播等现场预案。
 6. 前端采用 React，后端采用 Go + GORM，数据库采用 PostgreSQL；保持模块化单体和单仓库，不拆分微服务。
 7. 首期硬件范围只包含统一设备接口、成功/失败模拟器和测试日志，不接真实打印机、广播、LED 或扫码设备；真实硬件取得型号、协议、驱动、网络拓扑及回执能力后另行立项。
-8. 推荐先以一个项目做现场试点，跑通取号—固定 `N` 叫号—游客状态页/公示屏—到场—完成—预计时间校准的完整闭环，再扩展全景区。
+8. 推荐先以一个项目做现场试点，跑通多人取号—号码/人数叫号—游客状态页/公示屏—到场—完成—预计时间校准的完整闭环，再扩展全景区。
 9. 一个系统支持多个项目：所有队列、规则、票号、权限、设备和统计都带 `project_id`，但共用一套代码、数据库和部署，不为每个项目复制系统。
 
 ## 2. 已知需求、目标与边界
 
 ### 2.1 已确认需求
 
-- 员工端 H5：员工使用账号登录后只进行叫号和取号；每次叫下一批自动结束上一批，并按 FIFO 叫出固定数量的连续号码。
+- 员工端 H5：员工使用账号登录后进行取号和叫号；项目支持两种方式时同时展示号码栏与人数栏，每次叫号自动结束上一批并严格按 FIFO 选择连续号码。
 - 游客端 H5：查看自身排队情况、预计等待时间和当前进度。
 - 大屏 Web：实体公示屏公开展示最新叫号与队列概况；其公开投影继续使用绑定的只读地址。
 - 管理端 Web：统一承载运营概览、项目规则和大屏中心；大屏中心只展示公开票号与运行状态，并可进入管理员全屏监控。账号、权限、日志和真实硬件配置仍按后续范围扩展。
-- 一人一号；手机号必填，姓氏和称谓选填，称谓默认“游客”，不采集法定性别。
+- 一个号码可绑定多名同行游客；手机号和同行人数必填，姓氏和称谓选填，称谓默认“游客”，不采集法定性别。
 - 员工端、游客状态页和内部登录卡采用 390px 手机设计宽度；更窄设备缩到 100%，页面高度保持自适应。管理端和公示屏不套用此宽度。
 - 同一手机号允许创建多个活动号码；重复时先脱敏提示、再由员工确认并审计。
-- 每项目配置固定批量人数 `N`，严格 FIFO 呼叫队首连续号码，队列不足时呼叫全部剩余号码。
+- 每项目配置支持的叫号方式、单号人数范围，以及号码/人数两种方式各自的默认值与防误触单次上限。
 - 过号后原号码保持 `MISSED` 并失效；仍需排队时创建新号码进入队尾，原号码保留关联审计。
-- 预计等待时间统一按项目配置的单个号码间隔累加计算。
+- 预计等待时间统一按项目配置的单人间隔和本号前方实际人数累加计算。
 - 员工端和大屏端预留稳定硬件接口；首期只交付接口、模拟器和测试日志。
 - 中心服务是唯一写入权威，完全断网时停止数字化写入并执行人工预案。
 - 员工与管理员首期使用系统内置账号密码登录，预留后续 OIDC/SSO 接口。
@@ -60,7 +60,7 @@
 - 不使用机器学习、复杂滚动权重或预测平台；先用项目级简单参数计算预计等待时间。
 - 不承诺“精确到某一分钟”的等待时间。
 - 不把浏览器直连硬件作为唯一生产方案。
-- MVP 不开放游客远程自助取号；首期只做员工代取，游客自助取号属于 P1 独立范围。
+- 游客自助取号已按 2026-07-15 需求开放为当前实现：只允许选择正在运行的项目，使用手机号、选填姓氏/称谓和私密状态令牌；短信/微信通知仍不在范围内。
 - 不拆微服务，不引入通用工作流引擎、规则 DSL、事件溯源或独立消息中间件。
 - 不单独部署运营数据看板；它是管理端的一部分。
 - 不做跨项目自动调度、跨项目队列迁移或多租户计费；MVP 只做一个景区内的多项目隔离。
@@ -112,7 +112,7 @@
 | Qtrac | 官网有 customer or group 措辞，但不能证明 group 等于多张独立票；Auto Call 仍是逐个 | 浏览器大屏、语音、票据机/扫码可选；偏云端 | 有 API Library/Integration Hub 概述，无完整公开端点 | 采购前必须演示批量原子语义和断网行为 |
 | QLess | 有群组群发消息，未核验到批量改变多张票的叫号状态 | 通用 kiosk、monitor、短信/语音；偏云端 | 宣称 API 覆盖广，缺少公开端点/Webhook 细节 | 群发通知不能被当作批量叫号 |
 
-值得关注的景区类厂商案例是 [Waitwhile 的 SUMMIT One Vanderbilt](https://waitwhile.com/case-studies/summit-one-vanderbilt/)：游客扫码或由员工平板登记，填写同行人数，系统按设施吞吐召集下一组。案例数据属于厂商自报，其“设施吞吐 + 运营批次”思路可用于对照，但本项目已经确认采用“一人一号”，不采用该案例的同行组模型。
+值得关注的景区类厂商案例是 [Waitwhile 的 SUMMIT One Vanderbilt](https://waitwhile.com/case-studies/summit-one-vanderbilt/)：游客扫码或由员工平板登记，填写同行人数，系统按设施吞吐召集下一组。案例数据属于厂商自报；其“单号人数 + 运营批次”思路可用于对照，本项目仍使用更简单的连续 FIFO 规则。
 
 参考资料：[Waitwhile 多选与批量操作](https://help.waitwhile.com/en/articles/8061037-navigating-the-visits-page)、[Waitwhile 离线说明](https://help.waitwhile.com/en/articles/11603596-does-waitwhile-work-without-internet)、[Qmatic Serve View](https://docs.qmatic.io/en/staff-user-guides/user-guide--serve-view.html)、[Qmatic Queue Agent](https://docs.qmatic.io/en/service-and-branch-configuration/branch-configuration/about-branches.html)、[Qmatic Data Connect 限制](https://data-connect.docs.qmatic.io/developerguide.html)、[Wavetec 本地分支与云同步案例](https://www.wavetec.com/es/case-studies/wasl-properties-customer-experience-transformation/)、[Qtrac](https://qtrac.com/virtual-queuing/)、[QLess](https://www.qless.com/products/)。
 
@@ -141,8 +141,8 @@
 | 队列场次 `QueueSession` | 某项目在某营业日/时段的一条运行队列 | 营业日、开闭时间、状态、单调修订号、预计时间设置 |
 | 服务资源 `ServiceResource` | 通道、入口、船、车辆、窗口或操作位 | 类型、容量、在线状态、所属项目 |
 | 游客 `Visitor` | 受保护的最小访客资料，不以手机号唯一 | 内部 ID、加密手机号、手机号 HMAC 索引、选填姓氏、选填称谓、称谓默认“游客”、留存时间 |
-| 排队单 `QueueTicket` | 一位游客一次加入某队列的业务记录；一人一号 | 内部 ID、公开票号、私密查询令牌、顺序键、状态、来源、版本、可选原过号票关联 |
-| 叫号批次 `CallBatch` | 一次原子批量放行 | 批次序号、资源、固定目标人数 `N`、成员票 ID、操作人、项目设置快照、状态 |
+| 排队单 `QueueTicket` | 一个排队号码及其同行游客人数 | 内部 ID、公开票号、不可变 `party_size`、私密查询令牌、顺序键、状态、来源、版本、可选原过号票关联 |
+| 叫号批次 `CallBatch` | 一次原子批量放行 | 批次序号、叫号方式、请求数量、实际号码数、实际人数、成员票 ID、操作人、项目设置快照、状态 |
 | 叫号尝试 `CallAttempt` | 初叫、重叫及其渠道结果 | 次数、时间、到期时间、语音/屏幕/通知回执 |
 | 预计时间设置 `WaitEstimateConfig` | 每个项目当前使用的简单参数 | 模板、平均速度或批容量/间隔、缓冲分钟、上次修改人、上一版值 |
 | 预计时间记录 `WaitEstimateRecord` | 只记录关键业务节点的预计值 | 排队单、取号/叫号节点、预计区间、计算时间、项目设置摘要 |
@@ -201,15 +201,20 @@ MVP 只保留这四种状态。暂停、恢复和结束均记录操作人、原
 - [P1] 优先队列、人工插队和配额规则不进入 MVP。
 - 当日结束不批量物理删除；按状态关场并保留审计。
 - [P1] 手工修改位置不进入 MVP。
-- 一人一号使每张有效等待票都计为一人；不提供人数修改、同行组合并或拆分。
-- MVP 固定严格 FIFO：每次读取项目配置的 `N`，呼叫队首连续 `N` 张有效等待票；不足 `N` 时呼叫全部剩余票，不跳号、不手选。
+- 每张排队票保存创建时确认的 `party_size`；创建后不提供修改、拆分或合并，需纠正时取消原号并重新取号。
+- MVP 固定严格 FIFO：按号码时取队首连续 N 张；按人数时取合计人数不超过目标的最长连续队首。两种方式都不跳号、不手选。
 - 闭园前由管理员将项目切为 `PAUSED` 停止新取号/叫号，处理完现场后切为 `FINISHED`；复杂自动清队规则后移。
 
 ## 6. 批量叫号：完整业务定义
 
-### 6.1 MVP 只有一种模式
+### 6.1 项目可配置两种叫号方式
 
-`CALL_NEXT`：读取当前项目配置的固定批量人数 `N`，从队首按严格 FIFO 选择连续 `N` 张有效等待票；队列不足 `N` 时选择全部剩余票。员工界面只有“叫下一批”，不输入票数、不手选、不跳号。
+`CALL_NEXT` 接收明确的 `mode` 与 `count`：
+
+- `TICKET`：从队首选择最多 `count` 张连续有效等待票；队列不足时选择全部剩余票。
+- `PEOPLE`：从队首选择 `party_size` 合计不超过 `count` 的最长连续前缀。不得拆号或跳过大号；若队首单号人数已超过目标，则拒绝并提示所需最小人数。
+
+项目可配置只支持 `TICKET`、只支持 `PEOPLE` 或 `BOTH`。`BOTH` 时员工端同时展示两栏，不设置隐含默认模式。两种模式分别配置默认输入值和单次防误触上限；防误触上限不等同于项目容量上限。
 
 [P1] 手选、跳号、按班次和预叫只有在试点证明必要后再单独设计。
 
@@ -239,20 +244,21 @@ stateDiagram-v2
 1. 校验员工权限、资源归属和请求格式；若幂等键已有成功结果，直接返回原批次。
 2. 先锁定 `QueueSession`/队列修订行（或用 `UPDATE ... WHERE revision = expected` 做 CAS），再校验项目状态和客户端看到的修订号；修订不符立即返回冲突。
 3. 在同一串行化边界内，从队首按原始顺序读取等待票。
-4. 读取项目固定批量人数 `N`，选择队首连续 `N` 张有效等待票；不足时选择全部剩余票，并生成不可变成员快照。
+4. 校验项目是否支持请求模式及其防误触上限，按号码数或人数目标选择连续 FIFO 前缀，并生成包含模式、请求值、实际号码数、实际人数和成员的不可变快照。
 5. 创建 `CallBatch`、成员记录和首次 `CallAttempt`，把成员从 `WAITING` 更新为 `CALLED`。
 6. 增加队列修订号，同时写入审计和同库的“待发送事件”记录，然后提交。
 7. 提交成功后再发布实时事件、通知和硬件命令。
 
 多个员工同时叫号时，只能有一个事务在预期修订号上成功；后到请求在获得锁后会发现修订已变化，收到新的队列快照并要求重试，绝不继续使用旧候选集。
 
-API 语义固定为 `callNext(project_id)`；服务端读取该项目的固定批量人数 `N`。队列人数不足时叫出全部剩余号码，界面在提交前显示“将叫 X 个号码”。每个项目同一时间只保留一个尚未处理完的活动批次。
+API 语义为 `callNext(project_id, mode, count, expected_revision)`。服务端不信任客户端候选集，始终在锁内重新选择队首。响应同时返回实际号码数与实际人数；每个项目新一批叫号会自动完成上一活动批次。
 
-### 6.4 固定 N 与连续号码
+### 6.4 连续 FIFO 与“不超过目标”
 
-- 每张有效等待票代表一名游客，所以批次“票数”与“人数”相等。
+- 每张有效等待票代表一个号码，`party_size` 表示该号绑定人数；批次号码数与人数必须分别统计。
 - “连续”指队列顺序连续：只跳过已取消、已过号等非 `WAITING` 记录，不因票号数值存在自然缺口而回填或重排。
-- 队列剩余人数小于 `N` 时，本批呼叫全部剩余号码，不把这视为异常或欠载规则。
+- 人数模式只接受不超过目标的最长连续前缀；目标值可能未被填满，这是严格 FIFO 和不拆号的正常结果。
+- 号码模式仅限制本次号码数量，不另设这些号码的合计人数硬上限。
 - 大屏仅在公开票号数值确实连续时压缩为号段；否则完整列出本批票号，业务成员始终以 ID 列表为准。
 - [P1] 手选、跳号、轮椅位/舱位等多维容量约束在有明确项目需求时另行扩展。
 
@@ -270,13 +276,13 @@ API 语义固定为 `callNext(project_id)`；服务端读取该项目的固定
 游客默认看到：
 
 - 当前状态与公开票号；
-- 前方约多少个号码；
+- 前方号码数与前方实际人数；
 - 预计等待区间，例如 25–35 分钟；
 - 估算状态（正常、暂停、暂不可估）；
 - 最近更新时间；
 - 免责声明：现场运营、天气、设备和安全检查可能导致变化。
 
-一人一号后“前方号码数”就是前方人数；仍不显示“准确 29 分钟”，因为它会被游客理解为承诺。
+“前方人数”只统计本号前面的等待票 `party_size` 之和，不包含本号自身同行人数。仍不显示“准确 29 分钟”，因为它会被游客理解为承诺。
 
 ### 7.2 MVP 简单计算模板
 
@@ -284,9 +290,9 @@ API 语义固定为 `callNext(project_id)`；服务端读取该项目的固定
 
 | 模板 | 适用项目 | 简单计算 |
 |---|---|---|
-| 单号间隔 | 所有项目 | （前方有效号码数 + 1）× 单个号码预计间隔时间 |
+| 单人间隔 | 所有项目 | 前方实际人数 × 单人预计间隔时间 |
 
-两个模板均为首期能力，并由每个项目二选一。固定批次只按 FIFO 顺序和固定 `N` 计算，不建设装箱、排班或约束求解引擎；班次、车辆、多资源联合调度放到确有项目需要时再扩展。
+首期只保留单人间隔模板，不建设装箱、排班或约束求解引擎；班次、车辆、多资源联合调度放到确有项目需要时再扩展。
 
 预计值统一四舍五入到 5 分钟并显示为区间。项目暂停、权威队列数据陈旧或参数缺失时直接写“暂无法估算”，不叠加复杂修正系数；设备模拟失败不改变预计时间结果。
 
@@ -294,9 +300,7 @@ API 语义固定为 `callNext(project_id)`；服务端读取该项目的固定
 
 管理端每个项目只保留以下字段：
 
-- 计算模板：连续放行或固定批次；
-- 单个号码预计间隔时间；
-- 展示区间的固定缓冲分钟数；
+- 单人预计间隔时间；
 - 暂停时是否隐藏预计时间；
 - 最后修改人、修改时间和上一版值。
 
@@ -317,20 +321,20 @@ MVP 保存修改日志并允许恢复上一版，不做草稿审批流、定时
 | 模块 | MVP 能力 |
 |---|---|
 | 登录与工作台 | 必须账号登录；从已授权项目中选择当前项目，查看项目状态、网络和设备摘要 |
-| 取号 | 一人一号；手机号必填，姓氏/称谓选填，称谓默认“游客”，不采集法定性别；重复活动号码脱敏提示，员工确认后可继续并留审计；生成票号/二维码 |
-| 队列 | 等待/已叫/过号/到场列表，在账号项目授权范围内直接对应展示票号、完整手机号、姓氏/称谓、状态和取号时间；支持按手机号/票号搜索 |
-| 叫号控制台 | 主按钮“叫下一批”；按项目固定 `N` 自动选择队首连续号码，提交前显示号码数量和成员预览；叫号后可到场、完成 |
+| 取号 | 手机号和同行人数必填，姓氏/称谓选填；人数按项目范围校验且创建后不可修改；重复活动号码确认后可继续并留审计 |
+| 队列 | 等待/已叫/过号/到场列表逐号展示 `party_size`，并在账号授权范围内展示票号、完整手机号、姓氏/称谓、状态和取号时间 |
+| 叫号控制台 | 按项目展示号码栏、人数栏或两栏；提交后显示实际号码数、实际人数与成员预览，叫号后可到场、完成 |
 | 更多操作 | 重叫、过号、取消、过号后重新取新号、暂停/恢复；默认折叠，不占主流程；授权手选/重排放 P1 |
 | 设备 | 首期显示接口未启用/模拟成功/模拟失败、测试日志和降级指引 |
 
-关键体验：危险操作二次确认；批次预览展示固定 `N`、实际号码数量和成员票号；按钮响应后显示服务端批次号，不用乐观假成功掩盖并发冲突。
+关键体验：防误触上限在服务端强制；每个候选号码旁显示同行人数；按钮响应后展示服务端实际号码数与人数，不用乐观假成功掩盖并发冲突。
 
 ### 8.2 游客端 H5
 
 MVP 推荐使用取号后生成的随机查询链接/二维码进入个人状态页：
 
-- 票号、项目、取号时间；
-- 当前状态、前方号码数、预计等待时间区间、更新时间；
+- 票号、项目、本号人数、取号时间；
+- 当前状态、前方号码数、前方人数、预计等待时间区间、更新时间；
 - 被叫后明显的到场窗口、位置导航和核验码；
 - 暂停、停运、闭园等运营公告；
 - 取消排队（若业务允许）与隐私说明。
@@ -351,9 +355,9 @@ MVP 推荐使用取号后生成的随机查询链接/二维码进入个人状态
 | 模块 | 能力 |
 |---|---|
 | 运营看板 | 管理端首页；项目筛选、等待号码数/人数、正在叫号、近期吞吐、设备模拟异常和活动号码明细；活动号码在管理员权限内对应展示项目、票号、完整手机号、姓氏/称谓与状态 |
-| 景区与项目 | 项目、营业时间、票号前缀、固定 `N`、批次间隔、项目开关 |
-| 叫号设置 | 固定批量人数 `N`、宽限时间、允许重叫次数；高级重排策略不进入 MVP |
-| 预计等待设置 | 每项目只填写单个号码预计间隔时间；显示上一版值和修改日志 |
+| 景区与项目 | 项目、营业时间、票号前缀、单号人数范围、项目开关 |
+| 叫号设置 | 支持模式、号码/人数默认值及各自防误触上限、宽限时间；高级重排策略不进入 MVP |
+| 预计等待设置 | 每项目填写单人预计间隔时间；显示上一版值和修改日志 |
 | 账号与权限 | 账号、角色、项目范围、禁用、会话、重置、MFA/SSO 预留 |
 | 日志与报表 | 队列流转、员工操作、配置、登录、通知、设备日志与导出 |
 | 设备接口 | MVP 只配置“未启用/模拟器”、测试成功/失败和记录；注册、心跳、回执与驱动管理属于后续真实硬件专项 |
@@ -477,9 +481,9 @@ MVP 先定义设备适配接口和模拟器。只有确认的真实硬件无法
 
 以下是边界，不是最终 URL：
 
-- `POST /staff/tickets`：员工取号；含幂等键。
+- `POST /staff/tickets`：员工取号；含不可变 `party_size` 与幂等键。
 - `GET /staff/queues/{id}/snapshot`：员工队列快照和修订号。
-- `POST /staff/queues/{id}/call-batches`：执行“叫下一批”，固定 `N` 读取项目设置。
+- `POST /staff/queues/{id}/call-batches`：提交 `mode`、`count`、队列修订号与幂等键，服务端在锁内选择连续 FIFO 前缀。
 - `POST /staff/call-batches/{id}/recall`：重叫。
 - `POST /staff/tickets/{id}/arrive|serve|complete|miss|cancel`：明确状态动作。
 - `POST /staff/tickets/{id}/replacement`：为已过号票创建新票号并排到队尾，记录新旧票关联；不修改原票状态和位置。
@@ -512,7 +516,7 @@ MVP 先定义设备适配接口和模拟器。只有确认的真实硬件无法
 - 系统不采集法定性别；称谓只用于人工核对，不推断或记录性别。
 - 同一手机号可对应多个同时活动的号码。重复检测只触发脱敏提示和员工确认，不阻止创建；确认结果必须审计。
 - 系统身份使用内部 ID；公开身份使用票号；个人查询使用高熵令牌或验证码。
-- 未成年人仍按“一人一号”创建独立排队单，可复用监护人手机号，不额外采集儿童手机号或法定性别。
+- 同行人数可包含未成年人，不为组内每个人额外采集手机号、姓名或法定性别；联系人手机号可被多个活动号码复用。
 
 ### 13.3 存储与展示
 
@@ -555,7 +559,7 @@ MVP 先定义设备适配接口和模拟器。只有确认的真实硬件无法
 
 ### 14.2 核心指标
 
-- 当前/峰值等待号码数和人数（一人一号，两者数值一致）；
+- 当前/峰值等待号码数和人数（分别统计，不再假定两者相等）；
 - 今日平均/最长实际等待时长；
 - 每小时吞吐、批次人数、容量利用率；
 - 过号率、取消率、过号后重新取号率、人工跳过率；
@@ -587,8 +591,8 @@ MVP 先定义设备适配接口和模拟器。只有确认的真实硬件无法
 
 - 状态机单元/性质测试：所有允许和禁止的转移、逆向操作、营业日边界。
 - 并发测试：多员工同时叫下一批、客户端超时重试、重复提交、队列暂停竞态。
-- 固定 `N` 选号测试：严格 FIFO、队首连续 `N` 个有效等待号码、不跳号，队列不足时叫出全部剩余号码。
-- 预计时间测试：按单个号码间隔累加、暂停、参数缺失和五分钟取整。
+- 双模式选号测试：号码模式取队首 N 张；人数模式取不超过目标的最长连续前缀，并覆盖队首单号超目标、不拆号、不跳号和欠载结果。
+- 预计时间测试：只累加本号前方实际人数，覆盖前方 0 人、暂停、参数缺失和五分钟取整。
 - 实时测试：掉线补快照、事件缺口、乱序/重复事件、大屏旧声音不重播。
 - 设备接口测试：MVP 模拟成功/失败；[后续真实硬件专项] 再测网关超时、重复命令、坏载荷、离线、过期和部分设备失败。
 - 端到端测试：四端共享同一排队单/批次事实。
@@ -597,17 +601,18 @@ MVP 先定义设备适配接口和模拟器。只有确认的真实硬件无法
 
 ### 16.2 必过场景
 
-1. 两名员工同时叫“下一批 20 人”，成员无重复、顺序严格 FIFO 且两端得到明确结果。
+1. 两名员工基于同一修订号并发叫号，只有一方成功，成员无重复、顺序严格 FIFO 且两端得到明确结果。
 2. 服务端已成功、员工手机超时后重试，不生成第二批。
 3. 模拟语音适配器失败但公示屏成功，业务批次保持有效；真实设备重试语义留到后续专项验收。
 4. 大屏断线十分钟后恢复，只显示最新状态，不重播十分钟前语音。
 5. 项目暂停后停止新叫号，游客显示暂停而不是继续倒计时。
-6. 队列只剩 7 人而项目固定 `N=20` 时，原子叫出剩余 7 个号码，不等待凑满、不跳号。
-7. 过号后创建的新号码位于队尾，且可以追溯原号码、新号码、原因、操作人和所有叫号尝试。
-8. 已登录员工只能获得其授权项目的完整手机号对应数据，管理员可获得管理范围内的活动号码明细；游客只获得本人私密状态页中的手机号尾四位，大屏和设备令牌无法获得任何手机号或管理数据。
-9. 修改项目预计时间参数后立即生效、记录前后值，并可由授权管理员恢复上一版。
-10. 营业日结束、跨午夜、时区、时钟漂移和夏令时测试不破坏票号与统计。
-11. A 项目员工、SSE 订阅、公示屏令牌和设备绑定均无法读取或操作 B 项目数据；客户端伪造 `project_id` 也被服务端拒绝并留痕。
+6. 队首人数依次为 3、4、2，按人数目标 8 时只叫前两号共 7 人；不得越过第二号再选择第三号，也不得拆号。
+7. 队首单号 5 人而目标为 4 时拒绝叫号；提高到 5 后才允许叫出该号。
+8. 过号后创建的新号码位于队尾并继承原号同行人数，且可追溯原号码、新号码、原因、操作人和所有叫号尝试。
+9. 已登录员工只能获得其授权项目的完整手机号对应数据，游客只获得本人私密状态页中的手机号尾四位，大屏和设备令牌无法获得任何手机号或管理数据。
+10. 修改项目人数范围、叫号方式或预计时间参数后立即生效并记录前后值；既有号码的 `party_size` 保持不变。
+11. 营业日结束、跨午夜、时区、时钟漂移和夏令时测试不破坏票号与人数统计。
+12. A 项目员工、SSE 订阅、公示屏令牌和设备绑定均无法读取或操作 B 项目数据；客户端伪造 `project_id` 也被服务端拒绝并留痕。
 
 ## 17. 部署、弱网与灾备分支
 
@@ -635,19 +640,19 @@ MVP 以方案 A 和纸质号码、人工广播等应急预案为准。断网时
 
 ### 阶段 0：开发基线与脚手架（约 1 周）
 
-- 将 v1.0 已确认决策落实为领域模型、API 契约、数据库迁移和验收场景。
+- 将 v1.1 已确认决策落实为领域模型、API 契约、数据库迁移和验收场景。
 - 创建 React 前端、Go + GORM 后端和 PostgreSQL 的单仓库脚手架，接通本地开发与自动化测试。
 - 跟班观察普通日和高峰日，补充实际容量、网络与设备资料；这些现场输入用于校准，不改变已确认基线。
 
 ### 阶段 1：可运行垂直切片（约 2 周）
 
 - 先跑一个试点项目，但数据库和权限从第一天包含 `project_id`。
-- 员工一人一号取号、固定 `N` 批量叫号、游客状态页、公示屏更新和管理基础配置。
+- 员工多人取号、号码/人数双模式叫号、游客状态页、公示屏更新和管理基础配置。
 - PostgreSQL 事务、幂等、审计和设备模拟器从第一条链路就具备。
 
 ### 阶段 2：MVP 完整闭环（3–4 周）
 
-- 最小必要身份字段、重复手机号确认审计、到场/过号/新号排队尾，以及单个号码间隔的预计时间规则。
+- 最小必要身份字段、重复手机号确认审计、到场/过号/新号排队尾，以及按前方人数计算的预计时间规则。
 - 多项目选择、项目权限、管理端运营看板、日志报表、实时降级、隐私与安全加固。
 - 设备适配接口、成功/失败模拟器和测试日志；不加入真实设备适配器或本地网关。
 
@@ -667,10 +672,10 @@ MVP 以方案 A 和纸质号码、人工广播等应急预案为准。断网时
 
 ### MVP
 
-- 员工代取号，一人一号；手机号必填，姓氏/称谓选填，称谓默认“游客”，不采集法定性别。
+- 员工代取与游客自助取号均要求手机号和同行人数；单号人数按项目范围校验且创建后不可修改。
 - 同一手机号允许多个活动号码；员工确认重复提示后继续创建并留审计。
 - 一个系统支持多个项目；员工按授权选择项目，各项目独立队列、票号、参数、设备和统计。
-- 固定 `N` 批量叫下一批、严格 FIFO 连续号码、人数不足叫出剩余号码、重叫、到场、过号、过号后新号排队尾、取消、完成。
+- 项目可按号码、按人数或同时支持两种叫号；严格 FIFO、连续、不拆号、不跳号，并支持重叫、到场、过号、过号后新号排队尾、取消和完成。
 - 游客私密状态页；大屏公开投影；实时事件与轮询降级。
 - 简单的预计等待时间区间、暂停/停运降级。
 - 管理端运营看板，以及项目/设置/账号/权限/日志/设备管理。
@@ -682,7 +687,7 @@ MVP 以方案 A 和纸质号码、人工广播等应急预案为准。断网时
 
 ### P1
 
-- 游客现场扫码自助取号、短信/微信通知、票务/闸机凭证核验。
+- 短信/微信通知、票务/闸机凭证核验。
 - 优先队列、多个资源/班次、高级报表和预计时间统计、多语言，以及 AAA 级/专项辅助设备等无障碍增强。
 - 更多硬件驱动、设备远程诊断、离线部署增强和独立设备网关。
 - 员工手选、跳号、预叫、批次撤回和多维容量约束。
@@ -699,24 +704,24 @@ MVP 以方案 A 和纸质号码、人工广播等应急预案为准。断网时
 
 - 四类访问视图：员工 H5、游客私密状态 H5、实体只读公示大屏，以及包含运营概览、项目管理和大屏中心的 PC 管理端。
 - 一个系统支持多个景区项目，所有业务通过 `project_id` 强隔离，但不为每个项目重复部署。
-- 一人一号；手机号必填，姓氏/称谓选填，称谓默认“游客”，不采集法定性别。
+- 一个号码可绑定多名同行游客；手机号与同行人数必填，姓氏/称谓选填，称谓默认“游客”，不采集法定性别。
 - 同一手机号允许多个活动号码；重复时脱敏提示、员工确认并审计。
-- 每项目配置固定 `N`，严格 FIFO 呼叫队首连续号码；不足 `N` 时叫出全部剩余号码，不手选、不跳号。
+- 每项目配置单号人数范围、支持的叫号方式，以及两种方式各自的默认值和防误触单次上限；不增加独立项目总容量上限。
 - 过号后原号失效；重新排队必须创建新号进入队尾，并保留新旧票关联审计。
-- 预计等待时间只保留单个号码预计间隔时间，每个号码按该规则累加计算。
+- 预计等待时间只保留单人预计间隔时间，并按本号前方实际人数计算。
 - 中心服务是唯一写入权威；断网停写并切换纸质号码、人工广播等预案。
 - 员工和管理员使用内置账号密码、RBAC 与项目权限，预留 OIDC/SSO。
 - 前端 React，后端 Go + GORM，数据库 PostgreSQL；模块化单体、单仓库、版本化 SQL 迁移。
 - 首期硬件只做统一接口、成功/失败模拟器和测试日志。
 - 留存采用已确认的 30 天个人关联、90 天原始业务事件、至少 6 个月安全日志、1 年后台审计和 3 年影响评估相关记录。
-- MVP 由员工代取，游客自助取号放 P1；大屏只显示票号，不公开身份字段。
+- 员工代取和游客自助取号共用统一排队事实源；公开创建接口只返回票号、手机号尾号和私密状态令牌，大屏仍只显示票号。
 - 界面显示预计等待时间区间和更新时间，不承诺精确分钟，也不展示 ETA 缩写。
 
 ### 20.2 开发期间需要补齐的现场输入
 
 下列输入用于参数校准、现场验收和后续集成立项，不是开始开发的阻塞项，也不得被解释为上述基线仍未确认：
 
-- 试点项目的峰值容量、营业时间、默认 `N`、宽限时间、批次间隔和连续放行速度；
+- 试点项目的峰值容量、营业时间、单号人数范围、两种叫号默认值/防误触上限、宽限时间和单人间隔；
 - 景区 VI、员工设备、大屏尺寸/阅读距离与网络质量；
 - 纸质号码、人工广播、现场负责人和恢复联网后的应急切换流程；
 - 未来真实硬件的型号、协议、驱动、网络拓扑、回执能力和安全边界；
@@ -727,7 +732,7 @@ MVP 以方案 A 和纸质号码、人工广播等应急预案为准。断网时
 | 风险 | 应对与验证 |
 |---|---|
 | 批量叫号重复/跳号 | 服务端原子事务、幂等、队列修订号、并发压测和审计回放 |
-| 固定 `N` 与并发队列变更 | 锁定队列修订行后读取队首连续号码；覆盖人数不足、取消穿插和并发叫号测试 |
+| 双模式与并发队列变更 | 锁定队列修订行后读取队首连续号码；覆盖人数欠载、队首超目标、取消穿插和并发叫号测试 |
 | 预计时间被理解成承诺 | 区间、更新时间、停运降级；管理看板观察近期平均误差 |
 | 大屏泄露个人信息 | 独立公开读模型、默认仅票号、自动化隐私测试 |
 | 浏览器/硬件不兼容 | 首期用适配器契约和模拟器隔离；后续真实硬件专项再评估本地网关与指定设备认证清单 |
@@ -737,12 +742,12 @@ MVP 以方案 A 和纸质号码、人工广播等应急预案为准。断网时
 
 ## 21. 开发启动状态
 
-用户已经确认本文件的关键产品与技术决策，并明确授权开始执行。开发不再等待同行组、身份字段、认证方式、断网写入、真实硬件或留存期限等旧决策分支。
+用户已经确认本文件 v1.1 的关键产品与技术决策，并明确授权执行。人数与双模式规则以本次修订为准，替代旧版“一人一号/固定 N”描述。
 
 开发启动后按以下门槛推进：
 
 - 首个里程碑先完成单试点项目垂直切片，再扩展完整管理看板与多项目体验；
-- 状态机、固定 `N` 叫号、过号新号排队尾、项目隔离和留存任务必须进入自动化验收；
+- 状态机、号码/人数双模式叫号、过号新号排队尾、项目隔离和留存任务必须进入自动化验收；
 - 首批项目容量、峰值、网络、VI 和设备资料在现场 UAT 前核实并用于校准；
 - 隐私告知、展示、导出规则与已确认留存配置在正式上线前由责任人复核；
 - 中心服务断网停写、RPO/RTO、纸质号码与人工广播预案在试点切换前演练；