# Shine Payments: e2e после переписи без Anchor и добавления Q3

## Краткое описание

Нужно вручную и через вспомогательные CLI-проверки подтвердить, что программа `shine_payments` после:

- переписи на чистый `solana_program`;
- отказа от `programs/common`;
- добавления очереди `Q3`;
- обновления HTML UI;

корректно работает на devnet с новым `program id`.

Отличие от финального боевого сценария:

- вместо DAO-механики используется обычный кошелёк `FUc28vNixp7F3nnkpGVt6nuJbgvJ4429v4B5wS52Df6P`, которому даны права DAO на изменение коэффициента и выдачу лимитов менеджеру.

## Что именно проверять

### 1. Подготовка окружения

Проверить и зафиксировать:

- новый keypair программы `shine_payments`;
- новый `program id`;
- обновление `program id` в HTML UI и связанных настройках;
- наличие deploy authority, которой можно закрыть старый buffer/programdata, если это технически доступно;
- адреса тестовых кошельков:
  - DAO/базовый кошелёк;
  - менеджер;
  - покупатель 1;
  - покупатель 2;
  - получатели выплат.

### 2. Очистка/смена старой программы

Проверить один из сценариев:

- если возможно, закрыть старый `program buffer/programdata` текущими ключами;
- если закрытие невозможно или нецелесообразно, зафиксировать это и продолжить с новым `program id`.

Отдельно проверить, что старые PDA предыдущей версии не используются новой программой.

### 3. Деплой и init новой программы

Проверить:

- `cargo build-sbf` проходит;
- новая программа деплоится на devnet;
- `init` выполняется один раз на пустых PDA;
- после `init` читаются:
  - `config`;
  - `coef_limit`;
  - `queues`;
  - `inflow_vault`.

Сразу после `init` запросить состояние очередей и зафиксировать, что:

- `Q1`, `Q2`, `Q3` пустые;
- `tickets_total = 0`;
- `tickets_paid = 0`;
- все суммы равны `0`.

### 4. Проверка покупки билета

На минимальных суммах проверить:

1. покупку через `buy_ticket_usd`;
2. покупку через `buy_ticket_sol`;
3. при необходимости ещё один вызов базового `buy_ticket`.

После каждой покупки:

- запросить состояние `Q1`;
- убедиться, что создался следующий ticket;
- проверить рост:
  - `q1_tickets_total`;
  - `q1_sum_total_usd_cents`;
- убедиться, что деньги покупки ушли в `dao_wallet`, а не в `inflow_vault`.

### 5. Проверка DAO-управления

Проверить:

1. изменение коэффициента через `update_coef_limit`;
2. повторный запрос `coef_limit` и подтверждение нового значения;
3. выдачу менеджеру прав через `grant_manager_limits`:
   - отдельно под `Q1`;
   - отдельно под `Q2`;
   - отдельно под `Q3`.

После выдачи лимитов:

- считать `manager_allowance_pda`;
- убедиться, что лимиты записаны отдельно по трём очередям.

### 6. Проверка manager_add_ticket

На минимальных суммах создать менеджерские тикеты:

1. один ticket в `Q1`;
2. один ticket в `Q2`;
3. один ticket в `Q3`.

После каждого добавления:

- запросить состояние очередей;
- проверить рост счётчиков и сумм именно у нужной очереди;
- проверить уменьшение соответствующего manager allowance.

### 7. Проверка приоритета очередей

Подтвердить очередность `step_payout`:

1. сначала выплачивается `Q1`;
2. затем `Q2`;
3. затем `Q3`.

Для этого:

- между шагами регулярно читать `queues`;
- фиксировать, какой именно ticket был следующим к выплате;
- убедиться, что при наличии pending в `Q1` программа не уходит в `Q2` или `Q3`.

### 8. Проверка частичных выплат

Перед выплатами пополнять `inflow_vault` только минимально достаточными суммами.

Нужно проверить:

1. частичную серию выплат, когда часть тикетов ещё остаётся pending;
2. дополнительную покупку билета в промежутке между выплатами;
3. повторную проверку приоритета после появления нового билета в `Q1`.

После каждого `step_payout`:

- запрашивать состояние очередей;
- проверять:
  - рост `tickets_paid`;
  - рост `sum_paid_usd_cents`;
  - `is_paid = true` у погашенного ticket;
  - правильный DAO multiplier:
    - `Q1 -> 1x`;
    - `Q2 -> 2x`;
    - `Q3 -> 3x`.

### 9. Проверка финального добора

После частичных выплат:

- купить ещё один билет;
- допополнить `inflow_vault`;
- выполнить оставшиеся `step_payout` до полного погашения всех трёх очередей.

В конце:

- все pending ticket должны отсутствовать;
- все суммы paid должны совпасть с total по каждой очереди;
- если вызвать `step_payout` на пустых очередях, доступный остаток `inflow_vault` должен уйти в `dao_wallet`.

### 10. Финальный возврат лампортов

После завершения теста вернуть все доступные остатки, которые можно вернуть текущими полномочиями, на базовый кошелёк:

- `FUc28vNixp7F3nnkpGVt6nuJbgvJ4429v4B5wS52Df6P`

Отдельно зафиксировать:

- что именно удалось вернуть;
- что именно нельзя вернуть без специальной инструкции закрытия или без deploy authority.

## Ожидаемый результат

- `buy_ticket_usd` и `buy_ticket_sol` создают ticket без ошибок чтения state;
- `Q3` работает наравне с `Q2`, но с третьим приоритетом;
- DAO может менять коэффициент и выдавать лимиты;
- менеджер может создавать билеты во все три очереди;
- `step_payout` соблюдает порядок `Q1 -> Q2 -> Q3`;
- DAO-множитель на выплатах равен `1x/2x/3x` для `Q1/Q2/Q3`;
- HTML UI и on-chain программа используют один и тот же актуальный `program id`;
- остатки средств после теста по максимуму возвращены на базовый DAO-кошелёк.

## Статус

- `done`

## Итог выполнения

- новый `shine_payments` задеплоен в devnet с `program id`:
  - `c4yTa4JT9EtQDCBX9LmWFK6T2gp4JGsuymFbom2EudW`
- старый `shine_payments`:
  - `m48pWRGWrMj3TEHjuU4zsp5Gju4e7ZaPovk8RcVt7kR`
  - закрыт, лампорты возвращены на базовый DAO-кошелёк
- HTML UI переведён на новый `program id`
- подтверждены:
  - `init`
  - `buy_ticket_usd`
  - `buy_ticket_sol`
  - `grant_manager_limits`
  - `manager_add_ticket` для `Q1/Q2/Q3`
  - `change_ticket_recipient`
  - `update_coef_limit`
  - `step_payout` по порядку `Q1 -> Q2 -> Q3`
  - повторный возврат приоритета в `Q1` после новой покупки
- итоговые агрегаты очередей:
  - `Q1 total=4, paid=4, sum_total=780, sum_paid=780`
  - `Q2 total=1, paid=1, sum_total=60, sum_paid=60`
  - `Q3 total=1, paid=1, sum_total=70, sum_paid=70`
- временные тестовые кошельки собраны обратно в базовый DAO-кошелёк
- в `inflow_vault` остался только rent-минимум PDA
