① 一句话需求

注册页实体站下拉的两个判断必须分开：

现行前端会过滤禁用实体站。本次取消过滤：配置中的禁用站仍显示，但置灰且不可选。PAGCOR 因此能在下拉看到至少 5 个实体站；尚未完成实地审查的站先显示，审查完成前不可选。

② 术语写死表

③ 全局红线表

④ 范围

本期做

1. 注册页与推广注册页不再过滤禁用实体站（§1、§2）。
2. 启用项可选；禁用项置灰且不可选（§2、G2）。
3. 默认选中第一个启用项，并调整注册按钮条件（§2、§3）。
4. 后台保存配置时拒绝不存在的 ID；运行时遇到坏 ID 只跳过该项（§4）。
5. 重复 ID 去重并保留第一次出现的位置（§4、AC10）。
6. 注册提交时复核实体站，并补齐失败后的前端处理与提示（§3、AC9）。

本期不做

• 不改取列表接口、实体站管理、后台建号页（添加下级号、增加股东）与 默认实体站 配置。
• 不改实体站的新增、改名、ID、删除规则，也不开放玩家重新绑定。
• 不改注册流程的 OTP、KYC、NDRP、人工审核等既有行为；§3 只补齐既有实体站提交复核的输入条件与失败出口。
• 不影响已绑定玩家；13 张报表与 用户注册日志 仍可显示、筛选已禁用实体站。
• 不新增权限点、不做顶部轮播图、不反查某实体站被哪些品牌配置。
• 「至少显示 5 个」由运营配置保证，系统不写死最小数量，也不负责自动补值。
• 除 §5 的两条实体站提示外，不新增或改写其他文案。

1. 数据来源与作用域

1.1　配置位置：Backoffice ▸ 网站管理 ▸ 基本配置 ▸ 运营参数 ▸ 注册可选实体站列表。BRAND_A 与 BRAND_B 各自维护一份，实体站 ID 以半角逗号分隔，顺序就是前端显示顺序。

1.2　实体站的 ID、名称与状态以 运营管理 ▸ 实体站管理 为唯一来源。注册侧不保存本地清单、不维护 ID 与名称映射。

1.3　取列表接口继续回传配置中的全部实体站，禁用中的也回传。每项包含：

接口结构不变；后端不得按状态过滤。

1.4　规则同时适用于注册登录页与推广注册页。实体站下拉仍位于 OTP 之后、Login / Register 之前。

1.5　既有显示不变：实体站为必填的 Enum，取值来自接口，红星在 label 前；收起态名称过长显示 …，展开态自动换行显示全名。

2. 显示、可选与顺序

2.1　前端不得按状态过滤或改写接口回传的实体站名称。

2.2　顺序严格按照配置字符串。禁用项留在原位置，不置顶、不下沉、不另行排序。

2.3　默认选中配置顺序中第一个启用项。没有启用项时，不产生选中值。收起态仍显示第一项名称并使用置灰样式；该名称不得进入提交资料。

3. 注册按钮

3.1　按钮高亮必须同时满足：手机号格式通过、OTP 已填满 6 位、协议已勾选、已选中一个启用中的实体站。OTP 是否过期或正确，在点击后依 §3.2 判定。

3.2　任一条件不满足时，按钮使用置灰样式，但不可直接设为无法接收点击事件；点击后的判定顺序为：

手机号 → OTP → 协议 → 实体站

命中后立即停止，不继续检查后面的项目。OTP 先判过期，再判内容是否正确；冷却时间与有效期使用同一个计时器。

3.3　四项均通过后才发起注册。后端以提交当下的资料复核实体站 ID，必须同时满足：

• ID 存在。
• 状态为启用。
• ID 仍在当前品牌的 注册可选实体站列表 中。

任一项不满足，统一返回「实体站不可用」。不得向前端区分不存在、已禁用或未配置。整笔注册失败，不建立账号，也不写入实体站绑定。

3.4　前端收到「实体站不可用」后：留在注册页，保留手机号、OTP 与协议状态，清除实体站选择并重新取列表。这次异常刷新不自动选择默认项，玩家必须重新选择。

• 刷新后仍有启用项：显示 §5 的「所选实体站不可用」。
• 刷新后没有启用项：显示 §5 的「没有可选实体站」。
• 重新取列表失败：沿用注册页既有的网络错误处理。

4. 配置的空值、坏值与重复值

4.1　保存校验与运行时兜底都要保留；一个坏 ID 不得使整份配置失效。

4.2　不另设条数上限或最小数量校验，只受配置字段既有长度限制。PAGCOR 的 5 项按去重后实际显示数量计算。

4.3　后台可保存空配置或全部禁用的配置；运营负责确保至少有一个启用项。

4.4　配置描述栏沿用既有的 ID 与名称对照表；实体站管理 是唯一来源，两边不一致时以它为准。

本节的「运行时」只指配置解析。注册提交时收到的异常 ID 依 §3.3 处理，不得静默跳过后继续注册。

5. 文案

原型出现的提示语必须能在本表找到逐字出处。↪ 为平台通用文案，✅ 为本模块线上文案，📐 为本 PRD 拟稿；图标不是文案的一部分。

本需求新增前两条，其余六条不重做。两条实体站提示都不得说明 ID 不存在、已禁用、未配置或尚未通过 PAGCOR 审查。

6. 生效与存量

• 配置或实体站状态保存后，下一次取列表即使用新值；注册侧不缓存。
• 状态变更后，新进入页面的选项同步变为可选或置灰；既有绑定不变。
• 玩家选中后、提交前若配置或状态改变，以提交当下的后端复核结果为准。
• 报表仍可检索已禁用的实体站资料。

7. 待确认项

① Requirement in One Sentence

The registration Gaming Venue dropdown must separate two decisions:

The current frontend filters out disabled venues. Remove that filter. A disabled venue in the configuration remains visible but disabled and cannot be selected. PAGCOR can therefore see at least five venues in the dropdown; venues awaiting onsite review can be displayed but remain unselectable until review is complete.

② Fixed Terminology

③ Global Invariants

④ Scope

Included

1. Registration and campaign-registration pages no longer filter disabled venues (§1, §2).
2. Enabled items are selectable; disabled items use disabled style and are not selectable (§2, G2).
3. Default to the first enabled item and update the registration-button condition (§2, §3).
4. Reject nonexistent IDs when saving configuration; at runtime skip only the malformed ID (§4).
5. Deduplicate IDs while preserving the first position (§4, AC10).
6. Revalidate the Gaming Venue on registration submission and provide the frontend failure path and messages (§3, AC9).

Excluded

• Do not change the list API, 实体站管理, backend account-creation pages (添加下级号, 增加股东), or 默认实体站 configuration.
• Do not change venue creation, naming, ID, or deletion rules, and do not let players rebind.
• Do not change existing OTP, KYC, NDRP, or manual-review behavior. §3 only completes the input conditions and failure exit for existing venue validation.
• Do not affect already-bound players. The 13 reports and 用户注册日志 continue to show and filter disabled venues.
• Do not add permissions, a top carousel, or reverse lookup of which brands configure a venue.
• Operations guarantees at least five displayed items through configuration. The system has no hardcoded minimum and does not auto-fill values.
• Do not add or rewrite copy except for the two Gaming Venue messages in §5.

1. Source and Scope

1.1 Configuration path: Backoffice ▸ 网站管理 ▸ 基本配置 ▸ 运营参数 ▸ 注册可选实体站列表. BRAND_A and BRAND_B maintain separate values. Gaming Venue IDs are separated by ASCII commas, and their order is the frontend display order.

1.2 运营管理 ▸ 实体站管理 is the only source of venue ID, name, and status. Registration does not store a local list or maintain an ID/name mapping.

1.3 The list API continues to return every configured venue, including disabled venues. Every item contains:

The API shape is unchanged. The backend must not filter by status.

1.4 The rules apply to both the registration/login page and campaign-registration page. The dropdown remains after OTP and before Login / Register.

1.5 Existing display behavior remains: Gaming Venue is a required Enum sourced from the API, with the red asterisk before the label. A long name is ellipsized with … when collapsed and wraps to show the full name when expanded.

2. Display, Selectability, and Order

2.1 The frontend must not filter by status or rewrite the venue name returned by the API.

2.2 Order strictly follows the configuration string. Disabled items stay in their original position; do not move them up, down, or otherwise sort them.

2.3 Select the first enabled item in configuration order by default. If there is no enabled item, there is no selected value. The collapsed control may show the first item's name in disabled style, but that name must not enter the submitted data.

3. Registration Button

3.1 The highlighted button requires all four conditions: valid Phone Number format, six OTP digits entered, Policy selected, and one enabled Gaming Venue selected. OTP expiry and correctness are evaluated after the click under §3.2.

3.2 If any condition is not met, use the visually-disabled style but do not prevent the button from receiving clicks. Validate in this order:

Phone Number → OTP → Policy → Gaming Venue

Stop at the first failure. Check OTP expiry before correctness. Cooldown and validity use the same timer.

3.3 Start registration only after all four items pass. At submission time, the backend revalidates that the Gaming Venue ID:

• exists;
• is enabled; and
• remains in the current brand's 注册可选实体站列表.

If any check fails, return one unified “Gaming Venue unavailable” result. Do not tell the frontend whether the ID is nonexistent, disabled, or not configured. Fail the entire registration; do not create an account or write a venue binding.

3.4 When the frontend receives “Gaming Venue unavailable,” remain on the registration page, preserve Phone Number, OTP, and Policy state, clear the Gaming Venue selection, and reload the list. This exception refresh must not auto-select a default; the player must select again.

• If an enabled item remains, show “Selected venue unavailable” from §5.
• If no enabled item remains, show “No venue available” from §5.
• If reloading fails, use the registration page's existing network-error handling.

4. Empty, Malformed, and Duplicate Configuration

4.1 Keep both save validation and the runtime fallback. One malformed ID must not invalidate the full configuration.

4.2 Do not add a count limit or minimum count. Only the existing field-length limit applies. PAGCOR's five items are counted after deduplication from the items actually displayed.

4.3 The backend may save an empty configuration or one containing only disabled items. Operations is responsible for keeping at least one enabled item.

4.4 The configuration description retains the existing ID/name reference table. 实体站管理 is the only source; if the two differ, it is authoritative.

“Runtime” in this section means configuration parsing only. An abnormal ID submitted for registration follows §3.3 and must not be silently skipped while registration continues.

5. Copy

Every message shown in the prototype must have an exact source in this table. ↪ is shared platform copy, ✅ is production copy in this module, and 📐 is drafted by this PRD. Icons are not part of the copy.

Only the first two messages are added by this requirement. Neither Gaming Venue message may disclose whether the ID is nonexistent, disabled, unconfigured, or awaiting PAGCOR review.

6. Effect and Existing Data

• The next list request uses a saved configuration or venue-status change; registration does not cache it.
• On a new page entry, a changed status immediately changes the item to selectable or disabled style. Existing bindings are unchanged.
• If configuration or status changes after selection but before submission, use the backend state at submission time.
• Reports continue to retrieve data for disabled Gaming Venues.

7. Open Point