注册送礼活动 · PRD

作者 Luke　版本 v1.10　日期 2026-09-16　状态改版中　平台 BRAND_A & BRAND_B　类 P　模板基准 prd-html

模板调整：保留既有活动模板的差异式规格；补权限、跨品牌、并发与 Client 复用流程验收。Client 原型只验证既有领取链，不扩大客户端改版范围。

版本记录

版本	日期	变更摘要
v1.10	2026-09-16	补回生成待领取记录时将领取截止时间写入既有「活动派奖记录」备注栏，并补 D9、AC16 与算例。
v1.9	2026-09-16	套用正式交付模板与模块清单；补模板声明、明确目录、权限／异常／待确认项，以及跨品牌、并发与权限验收；业务规则不变。
v1.8	2026-09-15	补回客户端列表／详情 Banner 视觉清单，并列出复用提示语供原型逐字核对；无新增业务规则（附录 B、C）。
v1.7	2026-09-15	补新版 HTML spec 要求的 BO／Client 无图视觉清单；业务规则不变（附录 B）。
v1.6	2026-09-15	改为迭代差异稿；删除已复用规则，只保留差异与差异验收（§1–§5）。
v1.5	2026-09-15	依新版结构重写，并重绘资讯图表（L0、§1–§5）。
v1.4	2026-08-22	新增一页式资讯图表（L0）。
v1.3	2026-08-22	彩金与流水倍数改取领取当下配置；各活动独立计算领取截止（§3、§4）。
v1.2	2026-08-22	自我互斥改为模板固定；彩金于领取时确定所属活动与配置（§2、§4）。
v1.1	2026-08-22	统一资格用语；区分 KYC 可重试与永久失格；补齐流水余量规则（§1、§3）。
v1.0	2026-08-22	固定自动参与＋手动领取；新增领取过期；移除显示设备；调整礼金设置（§2–§4）。

L0 · 快速掌握

注册送礼活动 · 一页式资讯图表

① 一句话需求

沿用既有注册送礼活动，只把参与方式改为自动参与＋限期手动领取，并调整配置字段。

② 歧义词写死表

词	唯一含义	查
发放日	用户符合注册与首存条件的日期	§3
即时	不按周期累积，不代表立即入账	§2

③ 全局红线表

#	不变量	违反后果	查
G1	符合条件即自动生成待领取记录，不得出现申请参与	流程做回旧版	AC1、AC10
G2	领取期限从发放日起算；首存条件开启时从首存达标日起算	奖励生成即过期	AC3、AC4
G3	手动领取过期必填且可编辑，不得因周期即时而置灰	无法配置领取期限	AC2
G4	彩金与流水倍数取领取当下配置	实际到账与当前配置不一致	AC5
G5	存量活动不迁移，新字段不得改变旧活动行为	在途活动被静默改写	AC11

④ 范围

改动：仅做 D1–D9（§2–§5）。
复用：活动模板、首存送礼活动及平台既有能力（§1）。
不做：客户端版面、新报表、新账变类型、金额分档、库存与客服补发（§1）。

L1 · 完整规格

1. 复用基准

范围	处理
迭代基准	既有注册送礼活动＋原型「更新2」；本稿只写差异
活动模板	↪ 沿用既有字段、校验、时间边界、权限、列表、生命周期与归档；下文未列者不改
手动领取	↪ 复用「首存送礼活动」v1.11 的待领取、过期、前置检查、状态、账变、失败与并发机制
奖金限制	↪ 沿用场馆白名单与多笔彩金 FIFO；同一投注不重复计算，抵满余量不结转
提示语	↪ 逐字沿用上述既有流程；本需求不新增提示语

2. M1 基本信息

本节是 M1 差异的唯一出处。

ID	字段	差异
D1	活动申请与领取方式	🔒 固定「自动参与＋手动领取」；只显示该选项
D2	手动领取过期	新增；Integer `1–15` 天，必填、可编辑；周期即时也不置灰
D3	周期	新增；🔒 固定「即时」，建立后不可改
D4	是否自我互斥	新增；🔒 固定「互斥」，不给运营配置
D5	移除字段	显示设备、KYC 同人互斥

3. M2 参与门槛与领取期限

M2 字段沿用既有模板，只增加以下结果差异：

首存条件	生成待领取记录	发放日
关闭	注册符合注册时间范围	注册成功当日
开启	注册符合，且终身首存于活动期内到账并达标	首存达标当日

3.1 领取截止＝发放日＋手动领取过期天数，当日 00:00:00。记录生成后，修改天数不回溯。

3.2 每个活动独立计算领取截止。活动已结束时，只要展示时间与该笔领取截止仍有效，用户仍可领取。

4. M3 派奖策略与 M4 奖金使用限制

ID	模块	差异
D6	M3 礼金设置	固定单行，无新增／删除；栏名为 `指标`、`对应彩金（₱）`、`流水倍数（倍）`
D7	M3 指标	🔒 固定「注册账号」；无运算符与设定值
D8	M4 流水基数	🔒 固定「仅奖金」；`有效流水要求＝彩金 × 流水倍数`

对应彩金：Decimal 1.00–999,999.99，两位小数。
流水倍数：Integer 0–99；0 代表无流水要求。
对应彩金与流水倍数取领取事务开始时的当前配置。

5. M5、运营入口与存量

配置顺序固定为 M1 基本信息 → M2 参与门槛 → M3 派奖策略 → M4 奖金使用限制 → M5 其他信息。
本活动的列表操作不显示「申请参与」；历史申请记录保留可查。
存量活动不迁移。修改页保留原参与／领取方式；领取过期为空时不阻断保存。
派奖沿用 [+] Register Promo；不启用出账方向，不新增账变类型。
D9 活动派奖记录备注：生成待领取记录时，将依 §3.1 算出的领取截止时间写入既有「活动派奖记录」备注栏；沿用该表时间格式，后续修改期限不得回写已生成记录。

6. 权限、异常与待确认项

项目	结论
权限	不新增权限点；无活动配置权限时不显示入口，后端仍须拒绝读取与写入。
操作留痕	沿用活动模板既有操作日志，记录活动、变更前后值、操作人及时间。
领取异常／并发	沿用首存送礼 v1.11 的原子入账、幂等与同一笔领取串行化；失败不得留下部分入账。
品牌隔离	`userId + platformId` 是资格、待领取记录与幂等键的隔离边界；跨品牌不得共用记录。
待确认项	无。Client 原型是复用领取链的验收工具，不代表本期新增客户端版面。

附录 A：差异验收

A.1 差异验收

AC	P	验收场景	预期
AC1	P0	新建活动查看参与方式	只显示「自动参与＋手动领取」，且只读（`G1`）
AC2	P0	周期为即时	手动领取过期仍必填、可编辑（`G3`）
AC3	P0	首存条件关；`08-01` 注册，期限 `7` 天	截止为 `08-08 00:00:00`（`G2`）
AC4	P0	首存条件开；`08-01` 注册，`08-10` 首存达标，期限 `7` 天	截止为 `08-17 00:00:00`（`G2`）
AC5	P0	待领取期间彩金 `100→150`、倍数 `3→5`	领取 `150`、倍数 `5`（`G4`）
AC6	P1	两个活动期限分别为 `3`／`10` 天	两笔各自计算截止
AC7	P0	活动结束，但展示时间与单笔截止仍有效	仍可领取
AC8	P0	查看礼金设置	仅一行、三栏，无新增／删除
AC9	P1	查看配置区	M1–M5 顺序与编号正确
AC10	P0	查看本活动列表操作	不显示「申请参与」（`G1`）
AC11	P0	编辑旧活动	原参与方式不变；空领取期限不阻断保存（`G5`）
AC12	P0	领取成功检查账变	只有 `[+] Register Promo`
AC13	P0	同一 `userId` 分别在 BRAND_A／BRAND_B 达标	两平台各自建立待领取记录，截止与状态互不影响
AC14	P0	同一笔待领取记录并发点击两次 Claim	最多一笔入账、一个最终状态；另一次回既有幂等结果
AC15	P0	无活动配置权限的管理员直接打开新增页或呼叫写入 API	入口不可见且后端拒绝；不得只靠前端隐藏
AC16	P0	08-01 生成待领取记录、期限 7 天后查看活动派奖记录	备注栏显示截止 08-08 00:00:00；之后修改期限不回写

附录 B：关键算例

输入／动作	正确结果	验证
首存条件关；08-01 注册；领取过期 7 天	08-08 00:00:00 截止	`G2`、`AC3`
首存条件开；08-01 注册；08-10 首存达标；领取过期 7 天	08-17 00:00:00 截止	`G2`、`AC4`
待领取期间彩金 100→150、倍数 3→5 后领取	入账 150；有效流水要求 750	`G4`、`AC5`
同一 `userId` 在两个品牌达标	各自产生记录，不跨品牌去重	`AC13`
同一笔奖励同时送出两次领取请求	仅一次入账，状态单向收敛	`AC14`
08-01 生成记录、期限 7 天后改为 10 天	活动派奖记录备注仍保留原截止 08-08 00:00:00	`D9`、`AC16`

附录 C：复用提示语核对表（默认折叠）

↪ 仅供原型逐字验收；表内全部提示语均为复用，不属于本迭代新增需求。

复用提示语

场景	中文	English	反馈／后续
待领取	—	—	显示 Claim
领取成功	领取成功！彩金 ₱{金额} 已到账，完成 ₱{流水要求} 有效流水后可提款	Claimed! ₱{amount} has been credited. Complete ₱{turnover} in turnover before withdrawal.	Modal；隐藏 Claim
逾期作废	注册彩金已逾期	This Registration Bonus has expired.	Toast；隐藏 Claim
重复领取	该彩金已领取	This bonus has already been claimed.	Toast；隐藏 Claim
未登录	请先登录后继续	Please log in first to proceed.	Toast；引导登录
登录态过期	登录已过期，请重新登录	Session expired. Please log in again.	Toast；引导登录
未完成 KYC	因监管要求，请先完成实名认证（KYC）后领取	Due to the Regulatory Framework, you must complete your KYC verification to proceed.	Modal；保留 Claim
同 IP 拦截	本活动在您的网络下已被参与过	This activity has already been joined from your network.	Toast；隐藏 Claim
自我互斥	您已参与了互斥的优惠活动	You've already joined a conflicting promotion.	Toast；隐藏 Claim
用户黑名单	您的账户暂无法领取，如有疑问请联系客服	Your account is restricted. Please contact support.	Toast；隐藏 Claim
网络异常	网络连接中断，请检查网络后重试	Connection lost. Please check your network and try again.	Toast；保留 Claim
系统异常	系统繁忙，请稍后再试	Something went wrong. Please try again later.	Toast；保留 Claim

原型视觉清单（默认折叠）

原型视觉清单

视觉 ID	载体	用途	证据
`VIS-BO-NONE`	BO	后台原型不使用图片或图片占位。	仅呈现活动配置控件。
`VIS-CLIENT-001`	Client	活动列表 Banner 占位。	沿用既有活动列表卡片形制。
`VIS-CLIENT-002`	Client	活动详情 Banner 占位。	沿用既有活动详情页头图形制。

文档版本：v1.10 | 日期: 2026-09-16 | 作者: Luke | 文档状态：改版中

Registration Bonus · PRD

Author Luke　Source Version v1.10　Translation EN-1.3　Date 2026-09-16　Status In Revision　Platform BRAND_A & BRAND_B　Class P　Template Base prd-html

Template adjustment: Keeps the concise delta specification and adds deterministic permission, cross-brand, concurrency, and reused Client-flow acceptance. The Client prototype verifies the reused claim flow and does not expand the Client UI scope.

Version History

Version	Date	Change Summary
v1.10	2026-09-16	Restored the Campaign Award Record remark requirement for each generated claim deadline; added D9, AC16, and a deterministic case.
v1.9	2026-09-16	Applied the formal delivery template and module checklist; added template declarations, an explicit TOC, permissions/failures/open-points conclusions, and cross-brand, concurrency, and permission acceptance. Business rules are unchanged.
v1.8	2026-09-15	Restored the Client list/detail banner checklist and listed reused messages for exact prototype verification; no business rule was added (Appendices B and C).
v1.7	2026-09-15	Added the BO/Client no-image visual checklist required by the new HTML spec; business rules are unchanged (Appendix B).
v1.6	2026-09-15	Converted to an iteration diff document; removed reused rules and retained only the differences and their acceptance criteria (§1–§5).
v1.5	2026-09-15	Rewritten to the new structure and redrew the infographic (L0, §1–§5).
v1.4	2026-08-22	Added the one-page infographic (L0).
v1.3	2026-08-22	Changed the bonus and turnover multiplier to use the configuration at claim time; each campaign calculates its claim deadline independently (§3, §4).
v1.2	2026-08-22	Fixed self-mutex at the template level; the campaign and configuration for the bonus are determined at claim time (§2, §4).
v1.1	2026-08-22	Standardized eligibility terms; separated retryable KYC failure from permanent disqualification; completed the remaining-turnover rule (§1, §3).
v1.0	2026-08-22	Fixed automatic participation plus Manual Claim; added claim expiry; removed display device; adjusted bonus settings (§2–§4).

Table of Contents

L0 · Executive Summary

Registration Bonus one-page infographic

① Requirement in One Sentence

Reuse the existing Registration Bonus campaign, changing only the participation method to automatic participation plus time-limited Manual Claim and adjusting configuration fields.

② Fixed Terminology

Term	Only Meaning	See
Payout Date	The date on which the user meets the registration and first-deposit conditions.	§3
Immediate	No accumulation by cycle; it does not mean immediate crediting.	§2

③ Global Invariants

#	Invariant	Failure Impact	See
G1	Create a pending-claim record automatically when the conditions are met; Apply for Participation must not appear.	The flow reverts to the old version.	AC1, AC10
G2	The claim window starts on the Payout Date; when the first-deposit condition is enabled, it starts on the date the first deposit qualifies.	The reward may expire as soon as it is created.	AC3, AC4
G3	Manual Claim Expiry is required and editable; an Immediate cycle must not disable it.	Operations cannot configure the claim window.	AC2
G4	The bonus and turnover multiplier use the configuration at claim time.	The credited amount differs from current configuration.	AC5
G5	Do not migrate existing campaigns; new fields must not change their behavior.	In-flight campaigns are silently rewritten.	AC11

④ Scope

Changes: D1–D9 only (§2–§5).
Reuse: the Campaign template, First Deposit Gift campaign, and existing platform capabilities (§1).
Excluded: client layout, new reports, new balance-transaction types, amount tiers, inventory, and customer-service reissuance (§1).

1. Reuse Baseline

Scope	Handling
Iteration baseline	Existing Registration Bonus campaign plus prototype “Update 2”; this document states differences only.
Campaign template	↪ Reuse existing fields, validation, time boundaries, permissions, list, lifecycle, and archive behavior; anything not listed below remains unchanged.
Manual Claim	↪ Reuse pending claim, expiry, prechecks, statuses, balance transaction, failure, and concurrency handling from First Deposit Gift v1.11.
Bonus restrictions	↪ Reuse the Game Provider allowlist and FIFO across multiple bonuses; do not count the same bet twice, and do not carry remaining turnover forward after it is fully met.
Messages	↪ Reuse the above existing flow copy verbatim; this requirement adds no messages.

2. M1 Basic Information

This section is the sole source of M1 differences.

ID	Field	Difference
D1	Campaign Application and Claim Method	🔒 Fixed to “Automatic Participation + Manual Claim”; show this option only.
D2	Manual Claim Expiry	New; Integer `1–15` days, required and editable; remains enabled for an Immediate cycle.
D3	Cycle	New; 🔒 fixed to “Immediate” and immutable after creation.
D4	Self-Mutex	New; 🔒 fixed to “Mutex” and not configurable by Operations.
D5	Removed fields	Display Device and KYC Same-Person Mutex.

3. M2 Participation Threshold and Claim Window

Reuse existing M2 fields and add only these outcome differences:

First-Deposit Condition	Create Pending-Claim Record	Payout Date
Off	Registration falls within the registration window.	Registration-success date
On	Registration qualifies, and the lifetime first deposit is credited and qualifies within the campaign window.	First-deposit qualification date

3.1 Claim deadline = Payout Date + Manual Claim Expiry days, 00:00:00 on that date. Changes to the number of days do not apply retroactively after the record is created.

3.2 Calculate the deadline independently for each campaign. After a campaign ends, the user may still claim while both the display window and that record's claim deadline remain valid.

4. M3 Reward Strategy and M4 Bonus Usage Restrictions

ID	Module	Difference
D6	M3 Bonus Settings	Fixed to one row with no add/delete; columns are `Metric`, `Bonus Amount (₱)`, and `Turnover Multiplier (x)`.
D7	M3 Metric	🔒 Fixed to “Registered Account”; no operator or configured value.
D8	M4 Turnover Base	🔒 Fixed to “Bonus Only”; `Required Valid Turnover = Bonus Amount × Turnover Multiplier`.

Bonus Amount: Decimal 1.00–999,999.99, two decimal places.
Turnover Multiplier: Integer 0–99; 0 means no turnover requirement.
Use the current Bonus Amount and Turnover Multiplier at the start of the claim transaction.

5. M5, Operations Entry, and Existing Campaigns

Configuration order is fixed: M1 Basic Information → M2 Participation Threshold → M3 Reward Strategy → M4 Bonus Usage Restrictions → M5 Other Information.
The campaign list action does not show “Apply for Participation”; historical application records remain searchable.
Do not migrate existing campaigns. Their edit pages retain the original participation/claim method; an empty claim expiry does not block saving.
Reward crediting reuses [+] Register Promo; do not enable the debit direction or add a balance-transaction type.
D9 Campaign Award Record remark: when generating a pending claim record, write its §3.1 claim deadline into the existing Campaign Award Record remark column; reuse that table's time format and do not rewrite an existing remark after expiry changes.

6. Permissions, Failures, and Open Points

Item	Decision
Permission	Add no permission point. Hide the entry without campaign-configuration permission and reject reads and writes on the backend.
Audit	Reuse the campaign template operation log for campaign, before/after values, operator, and time.
Claim failures / concurrency	Reuse atomic crediting, idempotency, and serialization for one claim record from First Deposit Gift v1.11; failures leave no partial credit.
Brand isolation	`userId + platformId` isolates eligibility, pending records, and idempotency; brands never share records.
Open points	None. The Client prototype verifies the reused claim flow; it is not a new Client layout.

Appendix A: Difference Acceptance

A.1 Difference Acceptance

AC	P	Scenario	Expected
AC1	P0	View the participation method when creating a campaign.	Only “Automatic Participation + Manual Claim” appears, read-only (`G1`).
AC2	P0	Cycle is Immediate.	Manual Claim Expiry remains required and editable (`G3`).
AC3	P0	First-deposit condition Off; registration `08-01`; expiry `7` days.	Deadline is `08-08 00:00:00` (`G2`).
AC4	P0	First-deposit condition On; registration `08-01`; first deposit qualifies `08-10`; expiry `7` days.	Deadline is `08-17 00:00:00` (`G2`).
AC5	P0	While pending, bonus changes `100→150` and multiplier changes `3→5`.	Claim uses `150` and multiplier `5` (`G4`).
AC6	P1	Two campaigns have expiry values of `3` and `10` days.	Each record calculates its deadline independently.
AC7	P0	Campaign ended, but the display window and record deadline remain valid.	Claim remains available.
AC8	P0	View Bonus Settings.	One row and three columns only, with no add/delete.
AC9	P1	View the configuration sections.	M1–M5 order and numbering are correct.
AC10	P0	View the campaign's list action.	“Apply for Participation” is absent (`G1`).
AC11	P0	Edit an existing campaign.	The original participation method is unchanged; empty claim expiry does not block saving (`G5`).
AC12	P0	Check the balance transaction after a successful claim.	Only `[+] Register Promo` is created.
AC13	P0	The same `userId` qualifies in BRAND_A and BRAND_B.	Each platform creates its own pending-claim record; deadline and state are independent.
AC14	P0	Submit two concurrent Claim requests for the same pending record.	At most one credit and one final state; the other request returns the reused idempotent result.
AC15	P0	An administrator without campaign-configuration permission opens the create URL or calls the write API.	The entry is hidden and the backend rejects the request; frontend hiding alone is insufficient.
AC16	P0	A pending record is generated on 08-01 with 7-day expiry; inspect Campaign Award Record.	The remark shows 08-08 00:00:00; later expiry changes do not rewrite it.

Appendix B: Deterministic Cases

Input / Action	Correct Result	Verification
First-deposit condition Off; register on 08-01; expiry 7 days	Deadline is 08-08 00:00:00.	`G2`, `AC3`
First-deposit condition On; register 08-01; first deposit qualifies 08-10; expiry 7 days	Deadline is 08-17 00:00:00.	`G2`, `AC4`
While pending, bonus changes 100→150 and multiplier 3→5, then claim	Credit 150; required turnover is 750.	`G4`, `AC5`
The same `userId` qualifies in both brands	Create separate records; do not deduplicate across brands.	`AC13`
Submit two claim requests simultaneously for one record	Credit once and converge to one final state.	`AC14`
Generate on 08-01 with 7-day expiry, then change expiry to 10 days.	The Campaign Award Record remark keeps 08-08 00:00:00.	`D9`, `AC16`

Prototype Visual Inventory (Collapsed by Default)

Prototype Visual Inventory

Visual ID	Surface	Purpose	Evidence
`VIS-BO-NONE`	BO	The backoffice prototype uses no image or image placeholder.	It contains campaign configuration controls only.
`VIS-CLIENT-001`	Client	Campaign-list banner placeholder.	Reuses the existing campaign-list card pattern.
`VIS-CLIENT-002`	Client	Campaign-detail banner placeholder.	Reuses the existing campaign-detail hero pattern.

Appendix C: Reused Message Verification (Collapsed by Default)

↪ For exact prototype acceptance only. Every message is reused and is not a new requirement in this iteration.

Reused Messages

Scenario	Chinese	English	Feedback / Next Step
Pending	—	—	Show Claim.
Claim successful	领取成功！彩金 ₱{金额} 已到账，完成 ₱{流水要求} 有效流水后可提款	Claimed! ₱{amount} has been credited. Complete ₱{turnover} in turnover before withdrawal.	Modal; hide Claim.
Expired	注册彩金已逾期	This Registration Bonus has expired.	Toast; hide Claim.
Already claimed	该彩金已领取	This bonus has already been claimed.	Toast; hide Claim.
Guest	请先登录后继续	Please log in first to proceed.	Toast; guide login.
Session expired	登录已过期，请重新登录	Session expired. Please log in again.	Toast; guide login.
KYC incomplete	因监管要求，请先完成实名认证（KYC）后领取	Due to the Regulatory Framework, you must complete your KYC verification to proceed.	Modal; keep Claim.
Same-IP blocked	本活动在您的网络下已被参与过	This activity has already been joined from your network.	Toast; hide Claim.
Self-mutex	您已参与了互斥的优惠活动	You've already joined a conflicting promotion.	Toast; hide Claim.
User blacklisted	您的账户暂无法领取，如有疑问请联系客服	Your account is restricted. Please contact support.	Toast; hide Claim.
Network error	网络连接中断，请检查网络后重试	Connection lost. Please check your network and try again.	Toast; keep Claim.
System error	系统繁忙，请稍后再试	Something went wrong. Please try again later.	Toast; keep Claim.

Source document version: v1.10 | Translation: EN-1.3 | Date: 2026-09-16 | Author: Luke | Translation status: In Revision