09 — Prestige / Rebirth (vòng lặp lõi của idle)

Nguồn: chưng cất từ restore SOT com.Chodun.CatGunner 1.1.59 (BardCat). Mọi C# / công thức ở đây là L1 ANALYSIS — đọc từ ARM64 / Hex-Rays của libil2cpp.so tại RVA được ghi kèm. Không phải source gốc. Liên quan: 01-economy-money.md (Rebirth là một mắt trong chuỗi nhân thu nhập, và §7 đặc tả module kinh tế chạy độc lập), 07-progression-managers.md.

Mô hình tham chiếu chạy được: [F001: economy_reference_sim.py] hiện thực hoá toàn bộ mô hình dưới đây bằng Python thuần và tự kiểm với 70 vector — trong đó có việc tái tạo 8 mảng balance thật của scene, 0/360 lệch. Chạy để đối chiếu.

1. Vì sao prestige là vòng lặp lõi

Idle không có "hết game". Nó có reset có thưởng: người chơi tự nguyện vứt bỏ tiến độ đã tích để đổi lấy một multiplier vĩnh viễn, rồi chạy lại quãng đường cũ nhanh hơn nhiều lần. Toàn bộ nhịp "chơi vài giờ → reset → chơi lại nhanh gấp N" là nội dung của thể loại. CatGunner gọi nó là Rebirth (환생).

Tiền tệ prestige là RUBY (Gamemanager.Ruby, static InfVal @0x68). Rebirth không tốn gì cả — bạn trả bằng tiến độ, không bằng tiền — và trả về Ruby, thứ chỉ dùng để mua các node trong cây nâng cấp vĩnh viễn.

2. Stable truths

Mức bằng chứng: disasm-proven = đọc từ ARM64/Hex-Rays tại RVA đã ghi. metadata-proven = từ IL2CPP metadata đã giải mã (dump.cs) — tên/kiểu/offset/const chính xác. runtime-observed = đã thấy chạy trên thiết bị. derived = tính ra từ công thức disasm.

3. Mô hình hành vi

3.1 Kiến trúc hai tầng

Vòng ngoài — Rebirth()  [RVA 0x2B22AE0]
    reward = n^2.5 * relic% / 100      (n = Level_Now + 5*Stage_Now; 0 nếu Stage_Now <= 1)
    Get_Ruby(reward)                   -> PERSIST
    Rebirth_Count++                    -> PERSIST
    Money_Reset()                      -> RESET  (Money và Money_Accum)
    Upgrade_manager.Reset_Upgrade()    -> RESET  (mọi Upgrade_list[i].Lv = 0)
    Tree_manager.Rebirth_Reset()       -> RESET  (Stage_Now=0, Level_Now=0, Game_Exit+Game_Start)
    Cat_manager.Balance_Reload()       -> tính lại chỉ số mèo từ state mới

Vòng trong — Rebirth_Upgrade(num)  [RVA 0x2B22500]
    tiêu RUBY vào Upgrade_list[num]:  0=Damage, 1=Speed, 2=Money
    điều kiện: Lv < 20000  và  Price(Lv) <= Ruby

Điểm thiết kế: phần thưởng prestige không tự động thành sức mạnh. Nó là Ruby — một tiền tệ meta mà người chơi phải phân bổ vào một trong ba trục. Điều này thêm một quyết định vào mỗi vòng lặp và cho designer một cần gạt (đường cong giá) độc lập với đường cong kiếm thưởng.

3.2 Công thức của designer vs BẢNG ĐÃ SHIP — hai thứ khác nhau

Đây là bài học framework có giá trị nhất trong toàn bộ tài liệu, và nó suýt bị ghi sai.

Sự thật: Balance_Reload — hàm sinh bảng cân bằng — là DEAD CODE trong build 1.1.59. CodeRefsTo rỗng cho cả ba (Upgrade_manager 0x2B4A02C, Rebirth_manager 0x2B21CB4, Gun_manager 0x2B0AB4C); không có string literal (loại trừ Invoke/StartCoroutine theo tên); không có m_MethodName: Balance_Reload trong scene (loại trừ UnityEvent). Nó không bao giờ chạy.

Bảng thật lúc chạy là các mảng đã serialize trong Main.unity — gần như chắc chắn được một Editor script (không có trong build) chạy một lần rồi bake vào scene.

Upgrade_manager   Price_balance  @Main.unity:20353425     Power_balance @:20373428
                  Money_balance  @:20393431               Speed_balance @:20413434 (blob int32 LE)
Rebirth_manager   Value_balance[0..2] @:20451299 / :20491308 / :20531317
                  Price_balance  @:20571320
Tree_manager      Stage_Health_Balance @:20614934         Stage_Money_Balance @:20624935

Và các mảng đó KHÔNG khớp dạng đóng. Chúng được sinh bằng lặp có CẮT:

# Upgrade Money/Power — tái tạo mảng scene, 0/60 lệch
v = 100
for i in range(1, n): v = trunc3(v * 1.08)        # KHÔNG phải 100 * 1.08**i

# Upgrade Price — 0/60 lệch. Lưu ý 1.38 là DOUBLE NHỊ PHÂN 1.3799999999999998…
acc = 50
for i in range(1, n): acc = trunc4(acc * 1.38); price[i] = trunc3(int(acc))

# Rebirth Value[0] (Damage) và [2] (Money) — 0/60 lệch
value[lv] = trunc3(int(trunc3(1.05**lv * 100 - 100)))
# Rebirth Value[1] (Speed): 5 * lv        Upgrade Speed: 100 + 8 * lv     (khớp chính xác)

# Rebirth Price (Ruby) — 0/60 lệch
price[lv] = trunc3(int(trunc4(3 * (lv+1)**1.6)))

ToPrecision CẮT về phía 0, không làm tròn — xác nhận hai kênh độc lập: code (0x44E0E5C → ToExponent 0x44DF888 → set_exponent, chia BigInteger) và dữ liệu (1 202 phần tử mảng scene khớp 100 % mô hình cắt, 0 % mô hình làm tròn).

Sai lệch tích luỹ — vì sao dùng luỹ thừa là sai:

Ở lv 1 000, dạng đóng lệch ~6.5 lần (4.06e34 mảng vs 2.65e35 công thức). Sai số luôn theo một hướng (thấp hơn), vì cắt không bao giờ làm tăng.

Bảng prestige cũng vậy, chỉ nhẹ hơn (cắt một lần mỗi phần tử, không tích luỹ qua đệ quy):

Giá node prestige (Ruby) và giá upgrade thường, đọc thẳng từ mảng scene:

Mọi con số trong ba bảng trên đọc trực tiếp từ Main.unity, đã trích ra [F001: scene_balance_tables.json] và được mô hình tham chiếu tái tạo 0/360 lệch (mục test [M]). Phạm vi đã đối chiếu: lv 0…59.

Xác nhận cuối cùng: ảnh chụp save thật khớp cả BỐN giá trị

[device evidence: user_screenshot_stage5-4.png] (sha256 04ef8221…), Power/Speed/Money Lv.46:

4/4 khớp. Mô hình dựa trên công thức + làm tròn mà tài liệu này từng dùng cho 3.5a và 136b — sai 2/3 ô. Chính hai ô lệch đó là thứ chỉ ra rằng mô hình sai, chứ không phải panel hiển thị thứ khác. (Xem DECISIONS D008/D010.)

Xác nhận bằng mắt: panel Rebirth trên máy thật

[liveops catalog: 31_panel_Rebirth.png] (mở bằng chính Tree_manager.Content_Btn_Rebirth sau khi đặt Stage_Value_Max = 1000 trên save .sot riêng) xác nhận trực tiếp mô hình ở §3.1 và §3.4:

Sáu điểm dữ liệu độc lập, tất cả khớp. Đây là xác nhận đầu-cuối cho tầng prestige: từ mảng serialize trong scene → công thức disasm → con số hiện trên màn hình.

Bài học framework

Công thức mà designer viết ≠ bảng mà game ship. Ở đây chúng lệch tới 10 % ở lv 50 và 6.5 lần ở lv 1 000, chỉ vì một phép cắt 3 chữ số lặp lại — và vì 1.38 là double nhị phân.

Nếu bạn bake bảng cân bằng vào asset, bảng là nguồn sự thật, còn hàm sinh chỉ là công cụ Editor. Ai đọc hàm sinh rồi nghĩ mình đã hiểu nền kinh tế sẽ sai — theo một hướng nhất quán, ở mọi level cao. Với một bản restore, hệ quả trực tiếp: giữ nguyên mảng serialize; đừng gọi Balance_Reload lúc chạy. Gọi nó với một InfVal khác phiên bản (làm tròn thay vì cắt, hoặc 1.38 thập phân) sẽ sinh ra một nền kinh tế khác SOT.

3.3 Nối vào chuỗi thu nhập

// Gamemanager.MoneyValue_return — RVA 0x2A4E7B0 (runtime-verified)
r = value * Upgrade_manager.Money_return() / 100;   // = Money_balance[Lv] (mảng scene) -> RESET
r = r * Rebirth_manager.Money_return()     / 100;   // = Value_balance[2][Lv] + 100 -> BỀN qua rebirth
r = r * Skin_manager.Money_Accum           / 100;
r = r * Pet_manager.Pet_Money_Accum        / 100;
r = r * Relic_manager.Money_Value          / 100;
if (Money_Buff active) r = r * 3;

Đây chính là cơ chế "chạy lại nhanh hơn": mắt Upgrade_manager rơi về 100 % (trung tính) sau mỗi rebirth, còn mắt Rebirth_manager giữ nguyên và nhân lên trên mọi thu nhập kể từ giây đầu của vòng mới. Vì tất cả là phần trăm nhân nhau, prestige kéo giãn toàn bộ đường cong chứ không cộng thêm.

Ví dụ một chu kỳ đầy đủ (mô phỏng, mục [K] trong sim):

Trước rebirth:  Stage 10, Level 0, upgrade Money lv 25  -> mắt Upgrade = 653 %  (Money_balance[25])
Rebirth():      n = 0 + 5*10 = 50;  reward = 50^2.5 = 17 677 Ruby  (ToPrecision(5) CẮT)
                Money/Money_Accum -> 0 ; upgrade lv 25 -> 0 ; Stage/Level -> 0
Mua node:       17 677 Ruby mua được 40 level node Money (còn dư 270 Ruby)
Sau rebirth:    mắt Upgrade = 100 % (đã reset)  |  mắt Rebirth = 703 % (×7.03, vĩnh viễn)

Người chơi mất mọi thứ trong vòng, nhưng bước vào vòng mới với thu nhập ×7.03 — và mắt Upgrade sẽ lại leo lên 653 % nhanh hơn nhiều vì mọi đồng tiền kiếm được đều đã nhân 7.03. (Số liệu từ mô hình tham chiếu mục [K], chạy trên mảng scene thật.)

3.4 Đường cong thưởng và giá

Thưởng (RVA 0x2B22F18), tính từ tiến độ đạt được:

n = Tree_manager.Level_Now + 5 * Tree_manager.Stage_Now
reward = n^2.5 * Relic_manager.Rebirth_Value / 100      # ToPrecision(5) — CẮT, không làm tròn
if (Stage_Now <= 1) reward = 0                          # cổng chống farm rebirth sớm
if (is_UpgradeRebirth) reward *= 3                       # [R1] boost quảng cáo/IAP

Giá trị thật (relic 100 %, tính lại từ công thức — sim mục [J]):

Mũ 2.5 rất đáng chú ý: nó siêu tuyến tính theo tiến độ. Đi sâu gấp đôi ⇒ thưởng gấp 2^2.5 ≈ 5.66 lần. Đây là thứ khiến người chơi có động cơ đẩy xa thêm một chút trước khi reset, thay vì reset liên tục — và cùng lúc, Stage_Now <= 1 ⇒ 0 chặn hoàn toàn chiến thuật "rebirth spam".

Giá node — một bảng dùng chung cho cả 3 node, đọc thẳng từ mảng scene (Main.unity:20571320):

Chỉ liệt kê trong phạm vi đã đối chiếu với mảng scene (lv 0…59). Giá trị ở level cao hơn và điểm gãy ×1.002 (lv ≥ 14999) là UNKNOWN — chúng chỉ tồn tại trong Balance_Reload đã chết.

Giá là đa thức (lv^1.6) trong khi phần thưởng là siêu tuyến tính theo tiến độ và sức mạnh là lãi kép (1.05^Lv). Ba tốc độ khác nhau này là cái tạo ra nhịp: giá đa thức bị lãi kép vượt mặt về lâu dài, nên hệ thống tự mở dần. (Balance_Reload đã chết còn có một hệ số ×1.002/level từ lv 14999 dựng một bức tường mềm ở cuối; mảng scene chưa được đối chiếu ở tầm level đó — UNKNOWN.)

3.5 Biến thể "rebirth tăng cường" — và ranh giới R1

UpgradeRebirth_Able_return()          -> còn lượt hôm nay? (DailyLimit = 1)
UpgradeRebirth_IAP_Unlocked_return()  -> đã qua Stage_Value 989?
UpgradeRebirth_IAP_Able_return()      -> còn lượt IAP hôm nay? (IAP_DailyLimit = 1)
UpgradeRebirth_Start_By_Ad()   [R1]   RVA 0x2B233D0 -> thưởng ×3   (kind 1, hoặc 2 nếu đã mua Remove-AD-All)
UpgradeRebirth_Start_By_IAP()  [R1]   RVA 0x2B23454 -> thưởng ×3   (kind 3)
UpgradeRebirth_DayCheck()             -> so UpgradeRebirth_LastDate với Today_str_return()

Mẫu monetization điển hình của idle: nó không bán sức mạnh, nó bán tốc độ của vòng lặp — nhân 3 phần thưởng của một hành động người chơi vốn đã muốn làm. Giới hạn 1 lần/ngày cho mỗi kênh biến nó thành thói quen quay lại, không thành cửa hàng. Cổng IAP_UnlockStageValue = 989 chỉ mở kênh trả tiền sau khi người chơi đã tiến đủ sâu. Reset theo chuỗi ngày, không theo timestamp.

Các call-site R1 trong đường rebirth (ghi nhận, không dựng lại nội dung SDK):

Ràng buộc R1 tuyệt đối: binding mặc định là NullService fail-closed — trả ServiceResult.NotAvailable, không bao giờ cấp ×3. Một stub được phép log và no-op; nó không bao giờ được bịa ra một lần rebirth tăng cường.

4. Framework takeaway

4.1 IPrestigeLayer — bốn khái niệm

public interface IPrestigeLayer
{
    bool     CanPrestige { get; }        // ở CatGunner: luôn true, nhưng thưởng có cổng riêng
    BigNum   PreviewReward();            // ~ Rebirth_Reward_return()
    void     Prestige();                 // reset-set + trao meta-currency + count++
    int      PrestigeCount { get; }      // ~ Rebirth_Count
}

Tách "được phép reset" khỏi "reset có đáng không". CatGunner cho phép rebirth bất cứ lúc nào nhưng trả 0 nếu Stage_Now <= 1. Đây tốt hơn là khoá nút: người chơi luôn có thể thoát, hệ thống chỉ không thưởng cho hành vi thoái hoá.

4.2 Reset-set / Persist-set phải là khai báo

Sai lầm phổ biến: Prestige() gọi tay N hàm reset, và hệ thống thứ N+1 thêm sau đó bị quên → người chơi giữ lại thứ lẽ ra phải mất. Framework nên đảo ngược quan hệ:

[PrestigeScope(PrestigeScope.ResetOnPrestige)]   // hoặc .Persistent
public sealed class StageProgress : IPrestigeAware { public void OnPrestige() { … } }

Tầng prestige duyệt registry và gọi OnPrestige(); một hệ thống mới bắt buộc phải khai báo phe của nó. CatGunner làm việc này bằng kỷ luật con người (3 lời gọi tường minh trong Rebirth()) — chạy đúng, nhưng không có gì bắt buộc, và bằng chứng phủ định (súng/pet/relic/skin không hề được tham chiếu) là thứ phải đọc disasm mới biết.

4.3 Phần thưởng prestige là tiền tệ meta, không phải multiplier trực tiếp

Prestige()        -> cấp MetaCurrency (Ruby)
MetaUpgradeTree   -> node { Lv, MaxLv, ValueCurve(lv), PriceCurve(lv) }
IMultiplierSource -> tree.PercentFor(kind)      // cắm vào chuỗi nhân của doc 01

Nhờ vậy tầng prestige nối vào chuỗi nhân y hệt mọi nguồn khác (trả phần trăm, mặc định 100) — không cần trường hợp đặc biệt nào trong công thức kinh tế.

4.4 Ba tốc độ tăng trưởng, tham số hoá tách bạch

Bằng chứng từ SOT cho một bộ tham số rất sạch mà framework nên phơi ra nguyên vẹn:

Bài học thiết kế: tầng trong dốc và ngắn (giá hàm mũ vượt mặt sức mạnh hàm mũ ⇒ tự tắc nghẽn, buộc phải prestige); tầng prestige thoải và dài (giá đa thức thua sức mạnh hàm mũ ⇒ tự mở dần). Đó chính xác là hai vai trò cần có.

Framework nên tham số hoá mỗi tầng bằng đúng bộ này:

maxLevel, valueCurve(kind, lv), priceCurve(lv), softCapLevel, lateGrowth, quantizeDigits

4.5 Bảng đã bake là nguồn sự thật; hàm sinh chỉ là công cụ Editor

SOT bake bảng vào scene ở 3 chữ số có nghĩa, sinh bằng đệ quy có CẮT, với hằng số là double nhị phân. Hàm sinh (Balance_Reload) không bao giờ chạy trong build.

Nếu framework của bạn dùng double + pow(), bạn không ra "một game hơi khác" — bạn ra một game lệch 10 % ở lv 50 và 6.5 lần ở lv 1 000, và luôn lệch về một phía.

Ba điều framework nên bắt buộc: 1. quantizeDigits và luật cắt/tròn là tham số tường minh của đường cong, không phải mặc định ngầm. 2. "Đệ quy" hay "dạng đóng" là lựa chọn được ghi lại, vì hai cái cho kết quả khác nhau. 3. Nếu bảng được bake, bảng đi kèm một checksum và hàm sinh phải tái tạo được nó trong CI. Nếu không, hàm sinh sẽ âm thầm trôi khỏi dữ liệu đã ship — đúng như đã xảy ra ở đây.

4.5b Mốc mở khoá dùng một tiến độ ĐƠN ĐIỆU riêng, không dùng tiến độ hiện tại

Stage_Value_Max = max(Level_Now + 10·Stage_Now) là một giá trị chỉ tăng, ghi ở Game_Win, và không bị prestige reset. Toàn bộ thang mở khoá nội dung (20 / 30 / 50 / 90 / 110 / 110 / 340) đọc từ nó, không đọc từ Stage_Now hiện tại.

Đây là mẫu đúng và rất đáng chép: nếu cổng mở khoá đọc tiến độ hiện tại, mọi lần prestige sẽ khoá lại những gì người chơi đã mở — trải nghiệm tệ và là một lớp bug dễ mắc. Framework nên cung cấp sẵn một HighWaterMark riêng cho việc mở khoá, tách khỏi tiến độ vòng hiện tại.

4.6 State prestige là dữ liệu nhạy cảm

SOT dùng ObscuredInt (ACTk) cho level cây rebirth, không dùng int trần. Trong idle, prestige state là giá trị tài khoản; framework nên mặc định bọc nó và cung cấp điểm cắm cho lớp bảo vệ.

4.7 Booster prestige phải fail-closed

Mọi đường "nhân thưởng prestige bằng quảng cáo/IAP" đi qua interface, mặc định từ chối. Giới hạn theo ngày (chuỗi ngày + nguồn thời gian đáng tin), không theo timestamp cục bộ.

4b. Mô hình kinh tế THỨ HAI: thu nhập offline

Tài liệu này (và doc 01) mô tả nền kinh tế online. Có một mô hình thứ hai, tách hẳn, mà người chơi thật nhận phần lớn tiền qua đó.

Điểm cốt lõi: OfflineProgressSimulator.ApplyToManagers (RVA 0x2AB7398) ghi thẳng vào Gamemanager.Money / Money_Accum và chỉ gọi Get_Money((InfVal)0) để bắn OnMoneyChanged. ⇒ Offline KHÔNG đi qua MoneyValue_return.

Liên hệ với prestige: mắt Rebirth_manager.Money_return có được áp offline — nên cây prestige tiếp tục sinh lợi khi người chơi không mở game. Đính chính (G382): Relic_manager.Money_Value cũng được áp offline (bản trước ghi "không" — sai); Relic_manager.Offline_Value thì kéo dài cap. Hai relic, hai vai trò: một cái tăng tốc độ kiếm tiền (cả online lẫn offline), cái kia tăng thời lượng offline (tính bằng phút). Và mắt Rebirth Speed cũng vào tốc độ đánh của mô phỏng (atkSpd, luật 8) — prestige rút ngắn thời gian clear wave offline chứ không chỉ nhân tiền.

Bài học framework: hai mô hình kinh tế là có chủ đích. Dùng lại chuỗi online cho offline ⇒ cấp thừa; dùng lại mô hình offline cho online ⇒ cấp thiếu. Mô hình tham chiếu phơi chúng ra thành hai hàm có chữ ký khác nhau (offline_income_factor cố tình không nhận skin/pet/relic/buff) để không thể dùng sai. Chi tiết đầy đủ + bẫy khôi phục: 01 §5.8.

⚠ Rút lại: bản trước ghi "offline có thể cao hơn ~10 % nếu nhánh fallback chạy". Nhánh đó không thể chạy trong 1.1.59 (mảng có đúng 10 001 phần tử, chỉ số kẹp [0,10000]; instance luôn được Awake đặt trước vì chỉ có một scene). Giữ lại chỉ như một bẫy khôi phục — xem 01 §5.8.

Vị trí trong luồng boot (disasm-proven):

// LoadData.Load(data)
if (data == null) InitNewGame();
else OfflineProgressManager.instance.EvaluateAndApply(data, ContinueLoad);

CodeRefsTo(EvaluateAndApply) = đúng một người gọi: LoadData.Load. Tiến trình offline được đánh giá TRƯỚC mọi việc nạp state, và ContinueLoad được truyền vào làm continuation — nên popup "Chào mừng trở lại!" nằm trong luồng điều khiển, không phải hiệu ứng phụ. ContinueLoad rồi toả ra ~48 điểm gọi X.LoadFromSaveData(data). Thứ tự này là bắt buộc: offline ghi Gamemanager.Money và đẩy level upgrade, nên nếu manager nạp trước thì kết quả offline sẽ bị ghi đè. Chi tiết + định dạng save: 07 §3.2c.

UNKNOWN còn lại: số học chính xác của CalcFarmMoneyPerSec (0x2AB8A74) và CalcMoneyPerStage (0x2AB9128) — mới liệt kê được đầu vào của chúng, chưa dựng lại công thức (G194). Cửa sổ thời gian, máy trạng thái và các bảng Degree* thì đã đóng trong đợt 3 (G332, G334, G353).

5. Negative evidence & UNKNOWN

Đã ĐÓNG trong đợt này (trước đây là UNKNOWN)

Còn MỞ

⚠ Bài học phương pháp (đừng lặp lại)

Tài liệu này từng ghi "Rebirth_Btn_Locked_obj không hề được method nào tham chiếu" và kết luận điều kiện mở khoá là UNKNOWN.

Đó là một lỗi phương pháp. dump.cs chỉ liệt kê khai báo, nó không bao giờ cho thấy nơi một field được đọc/ghi. "Không thấy trong dump.cs" ≠ "không được dùng".

Cách đúng — và là cách đã tìm ra người ghi field đó:

DataRefsTo(<Il2CppClass* của class chủ>)  ->  decompile từng hàm  ->  tìm offset (+0x30 = "+ 48")

Cùng kỹ thuật (CodeRefsTo) là thứ chứng minh Balance_Reload là dead code — một kết luận không thể rút ra từ dump.cs.

6. Raw evidence

• [phân tích nội bộ] — U1–U4 + B-1…B-13; nguồn của bản đính chính lớn ở §3.2
• [F001: scene_balance_tables.json] — 8 mảng balance trích từ Main.unity (nguồn sự thật lúc chạy)
• [evidence codegen: PRESTIGE_RULES.md] — quy tắc gốc (một phần bị FABLE_ANALYSIS supersede: ToPrecision CẮT chứ không tròn; Balance_Reload là dead code)
• [evidence codegen: Rebirth.c] — Rebirth() RVA 0x2B22AE0
• [evidence codegen: Rebirth_Balance_Reload.c] — RVA 0x2B21CB4
• [evidence codegen: Rebirth_Reward_return.c] — RVA 0x2B22F18
• [evidence codegen: Upgrade_Balance_Reload.c] — RVA 0x2B4A02C
• [evidence codegen: MoneyValue_return.cs.evidence] — vị trí mắt Rebirth trong chuỗi
• dump.cs:598957 / :598987 / :602928 — khai báo + hằng số
• [runtime trace: runtime_ranking.json] — tần suất gọi thật
• [F001: economy_reference_sim.py] — mô hình tham chiếu chạy được (70/70 PASS)
• [device evidence: user_screenshot_stage5-4.png] — save thật (Stage 5-4, Lv.46), xác nhận Speed_balance[46] = 468
• [liveops catalog: liveops] — danh mục màn hình + cổng mở khoá (lane riêng, liên kết khi bàn giao)
• [restore project: Services] — ranh giới R1 fail-closed