Завдання Ring

Учасники надсилають одне одному завдання в чаті: опис, необов'язкового виконавця, кінцевий термін, бюджет і необов'язковий ескроу кредитів. Глобальне дерево /tasks містить список останніх завдань у всіх розмовах. Автори можуть перетворити завдання на особисту можливість request.

|| Шар | Де | ||-------|--------| || Типи | features/chat/types/index.ts — Message.type: 'task', TaskMetadata | || Модуль функції | features/tasks/** | || Серверні дії | app/_actions/tasks.ts | || API списків | GET /api/tasks, GET /api/tasks/conversation/[id] | || Сторінки | /tasks, /tasks/[chatId] | || Глибоке посилання на чат | /messages?c=<conversationId> (без сегмента /messages/[id]) |

Машина станів (спільна)

|| Статус | Значення | ||--------|---------| || available | Опубліковано без виконавця | || requested | Хтось попросив призначити його виконавцем | || in_progress | Виконавця призначено | || completed | Виконано автором або виконавцем | || accepted | Автор прийняв роботу (ескроу, якщо він утримується, вивільняється) | || canceled | Автор скасував (утримуваний ескроу повертається на кредитний баланс) | || disputed | Автор оскаржив після виконання, коли ескроу утримується |

Беклог

Завдання Ring

Учасники надсилають одне одному завдання в чаті: опис, необов'язкового виконавця, кінцевий термін, бюджет і необов'язковий ескроу кредитів. Глобальне дерево /tasks містить список останніх завдань у всіх розмовах. Автори можуть перетворити завдання на особисту можливість request.

|| Шар | Де | ||-------|--------| || Типи | features/chat/types/index.ts — Message.type: 'task', TaskMetadata | || Модуль функції | features/tasks/** | || Серверні дії | app/_actions/tasks.ts | || API списків | GET /api/tasks, GET /api/tasks/conversation/[id] | || Сторінки | /tasks, /tasks/[chatId] | || Глибоке посилання на чат | /messages?c=<conversationId> (без сегмента /messages/[id]) |

Машина станів (спільна)

|| Статус | Значення | ||--------|---------| || available | Опубліковано без виконавця | || requested | Хтось попросив призначити його виконавцем | || in_progress | Виконавця призначено | || completed | Виконано автором або виконавцем | || accepted | Автор прийняв роботу (ескроу, якщо він утримується, вивільняється) | || canceled | Автор скасував (утримуваний ескроу повертається на кредитний баланс) | || disputed | Автор оскаржив після виконання, коли ескроу утримується |

Беклог

Завдання Ring

Учасники надсилають одне одному завдання в чаті: опис, необов'язкового виконавця, кінцевий термін, бюджет і необов'язковий ескроу кредитів. Глобальне дерево /tasks містить список останніх завдань у всіх розмовах. Автори можуть перетворити завдання на особисту можливість request.

|| Шар | Де | ||-------|--------| || Типи | features/chat/types/index.ts — Message.type: 'task', TaskMetadata | || Модуль функції | features/tasks/** | || Серверні дії | app/_actions/tasks.ts | || API списків | GET /api/tasks, GET /api/tasks/conversation/[id] | || Сторінки | /tasks, /tasks/[chatId] | || Глибоке посилання на чат | /messages?c=<conversationId> (без сегмента /messages/[id]) |

Машина станів (спільна)

|| Статус | Значення | ||--------|---------| || available | Опубліковано без виконавця | || requested | Хтось попросив призначити його виконавцем | || in_progress | Виконавця призначено | || completed | Виконано автором або виконавцем | || accepted | Автор прийняв роботу (ескроу, якщо він утримується, вивільняється) | || canceled | Автор скасував (утримуваний ескроу повертається на кредитний баланс) | || disputed | Автор оскаржив після виконання, коли ескроу утримується |

Беклог

Контрольний список оператора

• Учасники знаходять Tasks поруч із Messages на бічній панелі (/tasks).
• Ескроу підтримує кредитний баланс, фіат (WayForPay/Stripe) і нативний токен через PaymentConductor (PaymentPurpose.task_escrow).
• Адміністраторське вирішення спорів: /admin/crm/task-escrows — вивільнення, повернення або примусове скасування утримуваних ескроу.

Сповіщення: NotificationType.TASK_ASSIGNED, TASK_UPDATED.

Контракт запиту /tasks

|| Кінцева точка | Поведінка | ||----------|----------| || GET /api/tasks?filter= | all | available | in_progress | completed — до 3 найновіших завдань на розмову, глобальний ліміт 21 | || GET /api/tasks/conversation/[id] | Усі завдання в одному чаті | || Відповідність фільтрів | available → available+requested; in_progress → in_progress; completed → completed+accepted |

Маршрути: ROUTES.TASKS, ROUTES.TASK(chatId) у constants/routes.ts.

Ескроу (credit_balance · fiat · native_token)

PaymentPurpose містить task_escrow (lib/payments/conductor/types.ts). Посилання на замовлення: task_{escrowId}_{timestamp}.

|| Подія | Поведінка | ||-------|----------| || Фінансування під час створення (кредит) | creditBalanceService.spendCredits → документ ескроу held + метадані повідомлення | || Фінансування під час створення (фіат/нативні кошти) | Документ ескроу в стані очікування → needsCheckout → POST /api/tasks/escrow/[id]/checkout | || Вебхук WFP/Stripe / вбудований нативний платіж | markHeldFromPayment → held + сповіщення автора | || Скасування до вивільнення | Кредит: addFiatUsd desk_refund + стабільний reference_id; WFP: refundStorePayment; нативні кошти: treasury→автор або резервний варіант — еквівалент у кредитах (як під час вивільнення) | || Прийняття після виконання | Кредит/фіат: addFiatUsd + reference_id; нативні кошти: treasury→виконавець або резервний варіант — еквівалент у кредитах | || Паралельне отримання | Справжній CAS: db().transaction + FOR UPDATE — лише одна з дій accept/cancel може отримати held | || Адміністраторське оскарження | /admin/crm/task-escrows — вивільнення / повернення / скасування через TaskEscrowService.adminResolve |

Колекція: task_escrows (документ JSONB через DatabaseService). Стабільні посилання реєстру: task_escrow_release_${id}, task_escrow_refund_${id} (зберігаються під час отримання до переміщення коштів).

Контрольний список операцій нативного ескроу

1. Спочатку перевірте стан купівлі desk (SOLANA_TREASURY_PRIVATE_KEY, SOLANA_FEE_PAYER_PRIVATE_KEY, RPC).
2. Виконавець/автор повинні мати кастодіальний нативний гаманець для виведення в блокчейн; інакше спрацьовує резервний варіант із кредитами.
3. Блокування hot-key у mainnet запускає резервний варіант із кредитами — це очікувана поведінка, а не завислий ескроу held.
4. Див. features/wallet/ops/TREASURY-SWAP-OPS.md § Task escrow.

Перетворення → можливість request

convertTaskToOpportunity (лише автор, не скасоване) викликає createOpportunity з type: 'request', isPrivate: true, visibility: 'subscriber', tags: [] і джерелом у metadata.source:

{ kind: 'chat_task', messageId, conversationId }.

Після цього завдання зберігає opportunityId у метаданих. Картки стрічки приховують застарілі теги sourceMessageId: / sourceConversationId: / chat_task через splitOpportunityTags (features/opportunities/lib/opportunity-tags.ts). Власник бачить чип From chat → /messages?c=<conversationId> (той самий запит, що й глибоке посилання на чат на цій сторінці). Немає зворотного заповнення, яке копіює старі закодовані теги в metadata.source.

Кроки інтеграції

1. 1

   Створіть завдання з композитора чату (ListTodo) — необов'язкові виконавець, кінцевий термін, кредитний бюджет і ескроу.

2. 2

   Співрозмовник натискає Start / Request → Done → автор натискає Accept (або Dispute, коли ескроу утримується).

3. 3

   Переглядайте /tasks або /tasks/[chatId]; відкривайте чат через /messages?c=.

4. 4

   За потреби перетворіть завдання на можливість → список запитів /opportunities.

Контрольний список оператора

• Учасники знаходять Tasks поруч із Messages на бічній панелі (/tasks).
• Ескроу підтримує кредитний баланс, фіат (WayForPay/Stripe) і нативний токен через PaymentConductor (PaymentPurpose.task_escrow).
• Адміністраторське вирішення спорів: /admin/crm/task-escrows — вивільнення, повернення або примусове скасування утримуваних ескроу.

Сповіщення: NotificationType.TASK_ASSIGNED, TASK_UPDATED.

Контракт запиту /tasks

|| Кінцева точка | Поведінка | ||----------|----------| || GET /api/tasks?filter= | all | available | in_progress | completed — до 3 найновіших завдань на розмову, глобальний ліміт 21 | || GET /api/tasks/conversation/[id] | Усі завдання в одному чаті | || Відповідність фільтрів | available → available+requested; in_progress → in_progress; completed → completed+accepted |

Маршрути: ROUTES.TASKS, ROUTES.TASK(chatId) у constants/routes.ts.

Ескроу (credit_balance · fiat · native_token)

PaymentPurpose містить task_escrow (lib/payments/conductor/types.ts). Посилання на замовлення: task_{escrowId}_{timestamp}.

|| Подія | Поведінка | ||-------|----------| || Фінансування під час створення (кредит) | creditBalanceService.spendCredits → документ ескроу held + метадані повідомлення | || Фінансування під час створення (фіат/нативні кошти) | Документ ескроу в стані очікування → needsCheckout → POST /api/tasks/escrow/[id]/checkout | || Вебхук WFP/Stripe / вбудований нативний платіж | markHeldFromPayment → held + сповіщення автора | || Скасування до вивільнення | Кредит: addFiatUsd desk_refund + стабільний reference_id; WFP: refundStorePayment; нативні кошти: treasury→автор або резервний варіант — еквівалент у кредитах (як під час вивільнення) | || Прийняття після виконання | Кредит/фіат: addFiatUsd + reference_id; нативні кошти: treasury→виконавець або резервний варіант — еквівалент у кредитах | || Паралельне отримання | Справжній CAS: db().transaction + FOR UPDATE — лише одна з дій accept/cancel може отримати held | || Адміністраторське оскарження | /admin/crm/task-escrows — вивільнення / повернення / скасування через TaskEscrowService.adminResolve |

Колекція: task_escrows (документ JSONB через DatabaseService). Стабільні посилання реєстру: task_escrow_release_${id}, task_escrow_refund_${id} (зберігаються під час отримання до переміщення коштів).

Контрольний список операцій нативного ескроу

1. Спочатку перевірте стан купівлі desk (SOLANA_TREASURY_PRIVATE_KEY, SOLANA_FEE_PAYER_PRIVATE_KEY, RPC).
2. Виконавець/автор повинні мати кастодіальний нативний гаманець для виведення в блокчейн; інакше спрацьовує резервний варіант із кредитами.
3. Блокування hot-key у mainnet запускає резервний варіант із кредитами — це очікувана поведінка, а не завислий ескроу held.
4. Див. features/wallet/ops/TREASURY-SWAP-OPS.md § Task escrow.

Перетворення → можливість request

convertTaskToOpportunity (лише автор, не скасоване) викликає createOpportunity з type: 'request', isPrivate: true, visibility: 'subscriber', tags: [] і джерелом у metadata.source:

{ kind: 'chat_task', messageId, conversationId }.

Після цього завдання зберігає opportunityId у метаданих. Картки стрічки приховують застарілі теги sourceMessageId: / sourceConversationId: / chat_task через splitOpportunityTags (features/opportunities/lib/opportunity-tags.ts). Власник бачить чип From chat → /messages?c=<conversationId> (той самий запит, що й глибоке посилання на чат на цій сторінці). Немає зворотного заповнення, яке копіює старі закодовані теги в metadata.source.

Кроки інтеграції

1. 1

   Створіть завдання з композитора чату (ListTodo) — необов'язкові виконавець, кінцевий термін, кредитний бюджет і ескроу.

2. 2

   Співрозмовник натискає Start / Request → Done → автор натискає Accept (або Dispute, коли ескроу утримується).

3. 3

   Переглядайте /tasks або /tasks/[chatId]; відкривайте чат через /messages?c=.

4. 4

   За потреби перетворіть завдання на можливість → список запитів /opportunities.

Контрольний список оператора

• Учасники знаходять Tasks поруч із Messages на бічній панелі (/tasks).
• Ескроу підтримує кредитний баланс, фіат (WayForPay/Stripe) і нативний токен через PaymentConductor (PaymentPurpose.task_escrow).
• Адміністраторське вирішення спорів: /admin/crm/task-escrows — вивільнення, повернення або примусове скасування утримуваних ескроу.

Сповіщення: NotificationType.TASK_ASSIGNED, TASK_UPDATED.

Контракт запиту /tasks

|| Кінцева точка | Поведінка | ||----------|----------| || GET /api/tasks?filter= | all | available | in_progress | completed — до 3 найновіших завдань на розмову, глобальний ліміт 21 | || GET /api/tasks/conversation/[id] | Усі завдання в одному чаті | || Відповідність фільтрів | available → available+requested; in_progress → in_progress; completed → completed+accepted |

Маршрути: ROUTES.TASKS, ROUTES.TASK(chatId) у constants/routes.ts.

Ескроу (credit_balance · fiat · native_token)

PaymentPurpose містить task_escrow (lib/payments/conductor/types.ts). Посилання на замовлення: task_{escrowId}_{timestamp}.

|| Подія | Поведінка | ||-------|----------| || Фінансування під час створення (кредит) | creditBalanceService.spendCredits → документ ескроу held + метадані повідомлення | || Фінансування під час створення (фіат/нативні кошти) | Документ ескроу в стані очікування → needsCheckout → POST /api/tasks/escrow/[id]/checkout | || Вебхук WFP/Stripe / вбудований нативний платіж | markHeldFromPayment → held + сповіщення автора | || Скасування до вивільнення | Кредит: addFiatUsd desk_refund + стабільний reference_id; WFP: refundStorePayment; нативні кошти: treasury→автор або резервний варіант — еквівалент у кредитах (як під час вивільнення) | || Прийняття після виконання | Кредит/фіат: addFiatUsd + reference_id; нативні кошти: treasury→виконавець або резервний варіант — еквівалент у кредитах | || Паралельне отримання | Справжній CAS: db().transaction + FOR UPDATE — лише одна з дій accept/cancel може отримати held | || Адміністраторське оскарження | /admin/crm/task-escrows — вивільнення / повернення / скасування через TaskEscrowService.adminResolve |

Колекція: task_escrows (документ JSONB через DatabaseService). Стабільні посилання реєстру: task_escrow_release_${id}, task_escrow_refund_${id} (зберігаються під час отримання до переміщення коштів).

Контрольний список операцій нативного ескроу

1. Спочатку перевірте стан купівлі desk (SOLANA_TREASURY_PRIVATE_KEY, SOLANA_FEE_PAYER_PRIVATE_KEY, RPC).
2. Виконавець/автор повинні мати кастодіальний нативний гаманець для виведення в блокчейн; інакше спрацьовує резервний варіант із кредитами.
3. Блокування hot-key у mainnet запускає резервний варіант із кредитами — це очікувана поведінка, а не завислий ескроу held.
4. Див. features/wallet/ops/TREASURY-SWAP-OPS.md § Task escrow.

Перетворення → можливість request

convertTaskToOpportunity (лише автор, не скасоване) викликає createOpportunity з type: 'request', isPrivate: true, visibility: 'subscriber', tags: [] і джерелом у metadata.source:

{ kind: 'chat_task', messageId, conversationId }.

Після цього завдання зберігає opportunityId у метаданих. Картки стрічки приховують застарілі теги sourceMessageId: / sourceConversationId: / chat_task через splitOpportunityTags (features/opportunities/lib/opportunity-tags.ts). Власник бачить чип From chat → /messages?c=<conversationId> (той самий запит, що й глибоке посилання на чат на цій сторінці). Немає зворотного заповнення, яке копіює старі закодовані теги в metadata.source.

Кроки інтеграції

1. 1

   Створіть завдання з композитора чату (ListTodo) — необов'язкові виконавець, кінцевий термін, кредитний бюджет і ескроу.

2. 2

   Співрозмовник натискає Start / Request → Done → автор натискає Accept (або Dispute, коли ескроу утримується).

3. 3

   Переглядайте /tasks або /tasks/[chatId]; відкривайте чат через /messages?c=.

4. 4

   За потреби перетворіть завдання на можливість → список запитів /opportunities.