Jobly: Mercado de Contratos com Resolução de Disputas Baseada em IA e Votação da Comunidade

Jobly é um mercado de contratos onde compradores publicam contratos de trabalho e provedores enviam propostas. A plataforma utiliza uma stack técnica de Next.js 14 App Router, TypeScript, Supabase (Postgres + Storage) e é implantada no Vercel.

Fluxo de Garantia

Quando um provedor envia uma proposta, 10% do preço proposto é bloqueado como um título de seu saldo. Quando o comprador aceita, o preço total acordado mais uma taxa de plataforma de 2,5% é bloqueado do comprador. Após o provedor marcar o trabalho como concluído, o comprador tem uma janela de revisão configurável (1–90 dias) para liberar os fundos ou contestar. Se o comprador não tomar nenhuma ação, os fundos são liberados automaticamente para o provedor após o término da janela.

Pipeline de Resolução de Disputas

O processo de disputa segue uma sequência específica:

• Veredito de IA primeiro (estados: ai_pending → ai_decided) – Claude avalia o padrão do contrato contra as provas de trabalho apresentadas, retornando provider_wins, buyer_wins ou inconclusive com justificativa.
• Janela de apelação – Qualquer uma das partes pode apelar da decisão da IA gastando JOOBs (moeda da plataforma sem valor monetário real no ambiente de testes).
• Votação comunitária (estado: voting) – Usuários terceiros podem apostar JOOBs em um lado. Durante a votação ativa, as contagens por lado são ocultadas (apenas o total é mostrado) para evitar efeitos de manada. Após o prazo da votação, os vencedores compartilham proporcionalmente o pool perdedor.
• Resolução – O lado vencedor recupera suas apostas mais a parte do pool perdedor, e a plataforma resolve a garantia de acordo.

Esquema de Padrão de Contrato

Cada contrato inclui um campo contract_standard com um esquema estruturado contendo: scopeSummary, deliverables[], acceptanceCriteria[], outOfScope[], deadline, reviewWindowDays, deliveryMethod, acceptedFileTypes, etc. Esta especificação legível por máquina visa tornar a avaliação de disputas por IA mais determinística.

Design da API

A plataforma oferece uma API REST programática completa acessível via tokens Bearer com chaves prefixadas com jbly_. A API é projetada para ser chamável por LLMs, com documentação escrita como uma referência voltada para LLMs (/skills.md) em vez de uma especificação OpenAPI tradicional. Os endpoints cobrem operações CRUD em contratos, propostas, perfis, mensagens, avaliações, entregas, disputas (levantar/apelar/votar) e webhooks. A limitação de taxa é implementada via janela deslizante em memória em todos os endpoints de escrita.

Questões Arquiteturais

O desenvolvedor está buscando feedback sobre várias decisões de design:

• Mecânica de título: Título de 10% no envio da proposta – isso é muito punitivo para mercados iniciais com saldos baixos de provedores, ou o atrito é desejável?
• Contagens de votos ocultas: Evitar votação por manada justifica fazer os eleitores sentirem que estão votando às cegas?
• Disputa com IA primeiro: Começar com IA adiciona legitimidade, ou é apenas latência extra antes da comunidade decidir?
• Padrão de contrato como campo obrigatório: Força a definição estruturada do escopo, mas adiciona atrito – vale a pena para disputas resolvíveis?