① 一句话需求

把会员的投注上限从每日一个窗口扩为日／周／月三个独立窗口；每笔成功投注同时累计三组金额，成交后判断达标，并依各窗口冷静期暂停后续投注。

② 术语写死表

③ 全局红线表

④ 适用范围与「不做」边界

本次包含客户端日／周／月设定、三组计数与冷静期、后台配置、Self-Limitation 报表、会员详情重置及对应文案。不改 Gaming Schedule 判断、投注金额定义或实际投注额报表栏。阅读者为客户端前端、投注后端、报表后端、运营配置、合规与测试。

2.1 时间窗口

2.1.1 边界归属以投注成功事件的发生时间判断。

2.2 累计事件

• 三个窗口沿用既有 Daily 的成功投注事件与投注额口径。
• 同一笔成功投注同时加入日、周、月三个计数；失败或未成立的投注不计入。
• 三个计数独立，任一窗口归零不得清除其他窗口计数。

2.3 达标顺序

1. 投注请求依既有流程成功成交。
2. 将该笔投注额同时加入三个窗口。
3. 对所有正数上限判断 累计额 ≥ 上限。
4. 达标窗口进入冷静期；从下一笔投注开始拦截。

2.3.1 不得拒绝、拆分或缩小跨过上限的那一笔；累计额可超过设定上限且须照实显示。这是刻意取舍：先让当前笔成交，再从下一笔停投，不是漏挡。

3.1 取值

3.1.1 三个上限选填且默认 0。只接受非负整数；0 表示不设限，不套最小值。正数超出已配置范围时夹至边界；配置边界为 0 表示该侧无界。改回 0 仍写一笔设定记录。范围提示为 Please enter {min}-{max}。

3.2 跨窗口校验

3.2.1 保存时只比较正数上限，并要求 Daily ≤ Weekly ≤ Monthly（日 ≤ 周 ≤ 月）；值为 0 的窗口跳过。失败时不保存，只在第一个违反顺序的输入列下显示 §9 校验文案。

3.2.2 例：Daily 0 时只校验 周 ≤ 月；Weekly 5,000、Monthly 20,000 合法。Daily 5,000、Weekly 1,000、Monthly 20,000 不合法。

3.3 客户端显示

3.3.1 Current turnover 显示自然周期投注额快照：进入弹窗时读取一次，离开弹窗前不刷新。三格为 Today／This Week／This Month；金额不封顶，只在各自自然周期边界归零，达到预警时显示红字。第二层显示三项当前上限；无限额时直接显示数值 0，不显示 No limit 文字。

3.3.2 限制判定计数不显示给会员。冷静期结束时只清该窗口的限制判定计数，不清自然周期投注额。例如画面已显示 Daily 120，冷静结束后判定计数归零；再将上限设为 300 并成功投注 300，即再次达标，画面显示 420。Weekly／Monthly 同规则。

4.1 触发与解封

4.1.1 多窗口在途时，实际解封取最晚时间。需求原文的 {解封时间} 即模板中的 {time}；冷静期间顶部常驻 Betting is paused until {time}.。

4.2 窗口结束

4.2.1 窗口冷静期结束时，同时解冻该窗口并清除其限制判定计数；自然周期投注额继续累计。冷静期中允许保存的新上限已于它的 Set Time 生效，本时点不再套用另一笔待生效值。其他窗口仍在冷静期则继续拦截。

4.3 通知

4.3.1 每窗口、每计数周期的预警与达标通知各最多一次，归零后重置。一笔同时跨预警与上限只发达标；同时推过多窗口也只发一条，取上限值最大者，同值按 Monthly → Weekly → Daily。其他窗口仍进入冷静期；{time} 取在途最晚解封时间。

7.1 视图与筛选

7.1.1 筛选与操作规则如下：

7.2 栏位

7.2.1 Period 只在 Bet Limit 视图显示。线上旧名 Daily Game Duration 改为 Gaming Schedule；Reach 100% 改为 Reach Limit／Reach Warning。Effective Time 不再显示或导出；开发实作中生效时间与 Set Time 是同一个值。

7.3 一行与字段口径

7.3.1 底层一位会员只保留一份 Self-Limitation 当前状态，其中包含 Gaming Schedule 与 Daily／Weekly／Monthly 三个 Bet Limit 窗口。修改时只覆写有改动的窗口，不新增报表历史记录。

7.3.2 Bet Limit 报表查询时将会员的当前状态依 Period 展开为最多三行：Daily、Weekly、Monthly 各一行。当前为未设置的窗口不出行；用户主动设为 0（无限制）时仍出行并显示 Set Value = —。会员修改设定时，同周期的报表行直接反映新的当前值；历史的改前／改后值、发生时间与来源由 Self-Limitation Audit Log 留存。运营 Reset 清除四项当前设定，报表不再出该会员的设定行；Reset 另写 Admin Action Log。

7.4 导出

7.4.1 导出当前视图和上一次成功查询的全部结果。Bet Limit 画面为 10 栏，但既有 Line 不导出，因此输出 9 栏；Gaming Schedule 画面为 9 栏，导出 8 栏。排序沿用现况。

7.4.2 输出 CSV（UTF-8 with BOM），档名为 SelfLimitation_yyyymmdd_hhmmss.csv；日期与时间取按下 Export 的当下，与查询区间无关。查询结果为 0 笔时仍可导出，档案只写当前视图的表头，不含数据列。

9.1 Bet Limit 常驻说明

9.1.1 删除旧句 1. Data: Usage is based on provider data and may have slight delays.。首行不随 self_limitation_pause_adjust 切换。

9.2 动态文案

9.2.1 长／短校验文案择一，不同时出现。冷静期间每次点击游戏都显示同一组 Reminder 文案。

9.3 运营重置文案

9.4 既有文案

9.4.1 Gaming Schedule 只把第一行换成 §9.1 首行，其余逻辑与上述两句不改。

① One-sentence requirement

Expand a member's single daily betting-limit window into independent daily, weekly, and monthly windows. Each successful bet adds to all three counters; after settlement, reached windows enter cooling-off and block subsequent bets.

② Fixed terminology

③ Global invariants

④ Scope and exclusions

Included: client daily/weekly/monthly settings, three counters and cooling-off periods, BO configuration, Self-Limitation report, member-detail reset, and exact copy. Do not change Gaming Schedule evaluation, bet-amount definition, or the actual-turnover report field.

2.1 Time windows

2.1.1 Assign a boundary event using the successful-bet event time.

2.2 Accumulation event

• All windows reuse the existing Daily successful-bet event and amount definition.
• The same successful bet adds to daily, weekly, and monthly counters; failed or unsettled bets do not count.
• Counters are independent. Resetting one must not clear another.

2.3 Evaluation order

1. Bet succeeds through the existing flow.
2. Add the amount to all three windows.
3. For every positive limit, evaluate accumulated amount ≥ limit.
4. Reached windows enter cooling-off; block from the next bet.

2.3.1 Do not reject, split, or reduce the bet that crosses the limit. Accumulated amount may exceed the configured limit and must display the actual value. This is deliberate post-settlement behavior, not a missed block.

3.1 Values

3.1.1 All three limits are optional and default to 0. Accept non-negative integers only. 0 means no limit and ignores minimum configuration. Clamp a positive out-of-range value to the configured boundary; boundary 0 means unbounded on that side. Changing back to 0 still writes a setting record. Range copy: Please enter {min}-{max}.

3.2 Cross-window validation

3.2.1 On save, compare positive limits only and require Daily ≤ Weekly ≤ Monthly; skip every 0. On failure, save nothing and show §9 copy below the first field that violates the order.

3.2.2 Example: Daily 0, Weekly 5,000, Monthly 20,000 is valid. Daily 5,000, Weekly 1,000, Monthly 20,000 is invalid.

3.3 Client display

3.3.1 Current turnover is a calendar-period turnover snapshot read once when the modal opens; it does not refresh before leaving the modal. The three values are Today/This Week/This Month. Values are uncapped, reset only at their own calendar boundary, and turn red at the warning threshold. The second layer shows current limits; an unlimited value displays the numeric value 0, never the text No limit.

3.3.2 Do not show the decision counter. Cooling-off end clears only that window's decision counter, not calendar-period turnover. If Daily displays 120, cooling-off ends, the limit is set to 300, and the next successful bet is 300, the limit is reached again while the UI displays 420. Weekly and Monthly behave the same.

4.1 Trigger and unlock

4.1.1 With multiple active windows, actual unlock is the latest time. Source {解封时间} maps to template {time}. During cooling-off, persistently show Betting is paused until {time}. at the top.

4.2 Window end

4.2.1 At a window's cooling-off end, unlock that window and clear its decision counter. Calendar-period turnover continues. A limit saved during cooling-off already took effect at its Set Time; no second value is applied here. If another window remains in cooling-off, betting stays blocked.

4.3 Notifications

4.3.1 Warning and reached notifications each fire at most once per window per decision cycle and reset with the counter. A bet crossing both warning and limit sends reached only. A bet crossing multiple windows sends one message using the largest limit; ties use Monthly → Weekly → Daily. All reached windows still enter cooling-off, and {time} is the latest active unlock.

7.1 Views and filters

7.1.1 Filters and query behavior are defined below:

7.2 Fields

7.2.1 Period appears only in Bet Limit. Rename production Daily Game Duration to Gaming Schedule; replace Reach 100% with Reach Limit/Reach Warning. Effective Time is neither displayed nor exported because the implementation uses Set Time as the effective time.

7.3 Row and field definitions

7.3.1 Store one current Self-Limitation state per member, containing Gaming Schedule plus the Daily, Weekly, and Monthly Bet Limit windows. A change overwrites only the windows actually changed and does not add report-history records.

7.3.2 At query time, the Bet Limit report expands the member's current state into at most three Period rows: one each for Daily, Weekly, and Monthly. A currently unset window has no row. A user deliberately setting 0 (no limit) still produces a row with Set Value = —. Updating a setting makes that period's row reflect the new current value. Historical before/after values, event time, and source are retained in the Self-Limitation Audit Log. Operator Reset clears all four current settings, removes the member's setting rows from the report, and writes the Admin Action Log.

7.4 Export

7.4.1 Export the current view and all rows from the last successful query. Bet Limit has 10 on-screen fields but excludes existing Line from export, producing 9 columns. Gaming Schedule has 9 on-screen fields and exports 8. Keep existing sort.

7.4.2 CSV, UTF-8 with BOM, filename SelfLimitation_yyyymmdd_hhmmss.csv. Timestamp is the moment Export is pressed, not the query range. Zero-row queries remain exportable and output current-view headers only.

9.1 Persistent Bet Limit text

9.1.1 Remove legacy 1. Data: Usage is based on provider data and may have slight delays.. The first line never changes with self_limitation_pause_adjust.

9.2 Dynamic copy

9.2.1 Choose either long or short validation text, never both. Every game click during cooling-off shows the same Reminder copy.

9.3 Operations reset copy

9.4 Existing copy

9.3.1 For Gaming Schedule, replace only the first line with §9.1's first line; keep other logic and the two strings above.