Documenta arquitectura, mapeamento de IDs e contratos API para ponte bidireccional entre portal wizard, Desk ops e FOSSBilling Support. Co-authored-by: Cursor <cursoragent@cursor.com>
1.9 KiB
1.9 KiB
Spec 044 — Tasks
Documentação
- Spec índice
spec.md - Contrato
contracts/ticket-field-mapping.md - Contrato
contracts/ticket-sync-api.md - Registo em
SPEC-REGISTRY.md - Ligações cruzadas specs 010/012/024/041/043
- Sync Obsidian VM130
Fase A — Estado actual (baseline)
- Portal OB- → Desk via
onboarding.escalated(VM112) - UI Desk mostra
wizard_ticket_id(OB-) no painel ticket - FOSS Support nativo em VM123 (sem bridge)
- Inventário endpoints FOSS Support API (Roger validar admin)
Fase B — Desk → FOSS (espelho)
- Coluna/payload
foss_ticket_idemtickets foss_client.create_support_ticket()— M2M admin API- Hook pós-criação ticket Desk: se
billing_accounts.external_customer_id→ espelho FOSS - Idempotência: não recriar se
foss_ticket_idjá existe - Unit tests
test_foss_ticket_sync_044.py
Fase C — FOSS → Desk (webhook)
- Endpoint
POST /api/v1/webhooks/foss/support(authFOSS_WEBHOOK_SECRET) - Plugin/hook FOSS ou cron poll — eventos
ticket.opened,ticket.reply,ticket.closed - Upsert nota / status no ticket Desk correlacionado
- Log em
webhook_eventssource=vm123-foss
Fase D — UI Desk
- Painel ticket: badge «FOSS #123» + deep-link
financeiro.ligbox.com.br/admin/support - Serviços IaaS / ficha cliente: «Abrir ticket FOSS» (roles sales_admin, sales_support)
- Central Operacional (041): evento
desk_ticketscomfoss_ticket_id
Fase E — Portal pós-activação
- Console
/me/suporteou FOSS client area — single entry (decisão Roger) - API Desk
POST /api/v1/support/tickets→ cria Desk + FOSS espelho - Resposta cliente inclui
tracking_url(portal ou FOSS)
Testes E2E
- Roger: OB- onboarding → activar conta → staff responde → cliente vê no FOSS
- Roger: cliente abre ticket FOSS → aparece no Desk Chamados