Переписать shine_payments и обновить тестовый UI с известным багом state

shine-solana/shine/doc/FUNDS_FLOW.md

@@ -31,9 +31,17 @@
 
 Источник выплат: `inflow_vault` (`ConfigState.inflow_vault`).
 
+Порядок очередей:
+1. сначала `Q1`;
+2. потом `Q2`;
+3. потом `Q3`.
+
 При шаге выплаты:
 1. Из `inflow_vault` переводится `ticket` получателю тикета.
 2. Из `inflow_vault` переводится DAO-часть в `dao_wallet`.
+   - для `Q1` это `1x payout_usd`;
+   - для `Q2` это `2x payout_usd`;
+   - для `Q3` это `3x payout_usd`;
 3. Из `inflow_vault` переводится `call_reward_lamports` вызывающему шаг.
 
 Если очереди пусты:

shine-solana/shine/doc/programs/shine_payments.md

@@ -2,11 +2,17 @@
 
 Документ описывает текущее целевое поведение программы `shine_payments`.
 
+Текущая целевая реализация программы:
+
+- без Anchor;
+- без использования вспомогательной зависимости из `programs/common`;
+- на чистом `solana_program` с ручным разбором инструкций, PDA и состояний.
+
 Назначение программы:
 
 - хранить общие настройки экономической модели платежей и выплат;
 - принимать покупку тикетов очереди выплат;
-- хранить очереди и отдельные ticket PDA;
+- хранить три очереди и отдельные ticket PDA;
 - выдавать лимиты менеджерам на ручное добавление тикетов;
 - выполнять пошаговые выплаты из inflow-вольта.
 
@@ -44,6 +50,7 @@
 
 - queue 1 seed prefix: `shine_payments_q1_ticket`
 - queue 2 seed prefix: `shine_payments_q2_ticket`
+- queue 3 seed prefix: `shine_payments_q3_ticket`
 - второй seed: `ticket_index` в little-endian `u64`
 
 ### 3.3. Manager allowance PDA
@@ -88,6 +95,10 @@
 - `q2_tickets_paid`
 - `q2_sum_total_usd_cents`
 - `q2_sum_paid_usd_cents`
+- `q3_tickets_total`
+- `q3_tickets_paid`
+- `q3_sum_total_usd_cents`
+- `q3_sum_paid_usd_cents`
 
 ### 4.4. `TicketState`
 
@@ -109,6 +120,7 @@
 - `manager_wallet: Pubkey`
 - `q1_available_usd_cents: u64`
 - `q2_available_usd_cents: u64`
+- `q3_available_usd_cents: u64`
 
 ### 4.6. `VaultState`
 
@@ -184,7 +196,7 @@
 ### Поведение
 
 - создаёт `manager_allowance_pda`, если её ещё нет;
-- увеличивает доступные лимиты Q1/Q2 для указанного менеджера;
+- увеличивает доступные лимиты Q1/Q2/Q3 для указанного менеджера;
 - не добавляет тикеты сама.
 
 ## 9. Инструкции покупки тикета
@@ -226,7 +238,7 @@
 
 ### Назначение
 
-Дать менеджеру возможность вручную создать ticket в `Q1` или `Q2`.
+Дать менеджеру возможность вручную создать ticket в `Q1`, `Q2` или `Q3`.
 
 ### Авторизация
 
@@ -234,7 +246,7 @@ Signer должен совпадать с `manager_wallet` в `manager_allowance
 
 ### Проверки
 
-- `queue_id` только `1` или `2`;
+- `queue_id` только `1`, `2` или `3`;
 - `payout_usd_cents > 0`;
 - доступный allowance по очереди не меньше суммы тикета;
 - ticket PDA ещё не существует.
@@ -254,7 +266,8 @@ Signer должен совпадать с `manager_wallet` в `manager_allowance
 ### Выбор очереди
 
 - если в `Q1` есть pending ticket, сначала обслуживается `Q1`;
-- если `Q1` пустая, обслуживается `Q2`.
+- если `Q1` пустая, обслуживается `Q2`;
+- если `Q1` и `Q2` пустые, обслуживается `Q3`.
 
 ### Что считается pending
 
@@ -291,11 +304,13 @@ next_index = tickets_paid + 1
 
 - для `Q1` = `1`
 - для `Q2` = `2`
+- для `Q3` = `3`
 
 То есть DAO получает:
 
 - `1x payout_usd` для Q1;
-- `2x payout_usd` для Q2.
+- `2x payout_usd` для Q2;
+- `3x payout_usd` для Q3.
 
 ### Источник денег
 
@@ -303,7 +318,7 @@ next_index = tickets_paid + 1
 
 ### Если pending нет
 
-Если обе очереди пусты:
+Если все три очереди пусты:
 
 - весь доступный остаток inflow vault переводится в DAO wallet.
 
@@ -324,7 +339,8 @@ next_index = tickets_paid + 1
 Логика:
 
 - если в `Q1` есть pending — следующий ticket определяется в `Q1`;
-- иначе берётся следующий ticket в `Q2`;
+- иначе если в `Q2` есть pending — следующий ticket берётся в `Q2`;
+- иначе следующий ticket берётся в `Q3`;
 - если текущий ticket и есть этот ближайший ticket, смена recipient запрещена.
 
 ## 13. Pyth oracle и конвертация
@@ -369,8 +385,8 @@ next_index = tickets_paid + 1
 
 - те же PDA seed-правила;
 - те же состояния и поля;
-- ту же модель очередей Q1/Q2;
-- ту же приоритетность `Q1` над `Q2` в `step_payout`;
+- ту же модель очередей Q1/Q2/Q3;
+- ту же приоритетность `Q1 -> Q2 -> Q3` в `step_payout`;
 - ту же логику allowance менеджера;
 - те же oracle-ограничения и округления;
 - ту же текущую модель денежных потоков, если она не меняется отдельным решением.