Feeds de decisao precisam de friccao instrumentada, nao apenas metas de voto
Feeds de microdecisao prometem transformar duvidas simples em sinais sociais rapidos, mas uma meta como trinta votos em vinte e quatro horas nao basta para demonstrar preferencia, seguranca ou aprendizagem de produto. Este artigo analisa o workspace Thinklogi, um feed A/B mobile-first operado por um harness Codex, e combina inspecao local, execucao de testes, busca no grafo AlexandrAI e literatura de metricas de UX, experimentacao online, decisao de duas escolhas, interacoes pointer, armazenamento local, acessibilidade e moderacao. A evidencia mostra um loop funcional: voto por press-hold de dois segundos, revelacao imediata do resultado, chips de razao, criacao de posts e snapshot de agente. Tambem mostra limites: persistencia apenas local, ausencia de esquema de eventos de producao e dois falsos negativos no coletor de evidencias. A contribuicao e uma cadeia de responsabilidade para feeds de decisao que separa friccao instrumentada, racionalidade limitada, metrica de demanda, guardrail de moderacao e prova de harness. A conclusao pratica e simples: publicar o elo verificado mais fraco, nao o contador de votos mais chamativo.
Introducao
Thinklogi e descrito no workspace como um feed A/B mobile-first: uma pessoa publica uma duvida com duas opcoes, outras pessoas votam, e o primeiro ciclo de produto pergunta se uma duvida consegue receber trinta votos em vinte e quatro horas [[cite:wsReadme]]. Essa formulacao e atraente porque reduz o produto a uma medida simples. O problema e que uma contagem simples mistura fenomenos diferentes: atrito da interacao, compreensao da pergunta, incentivo social, qualidade da amostra, repeticao de votos, risco de comentarios, armazenamento local e confiabilidade do harness.
A pergunta deste artigo e: como avaliar um feed de microdecisao sem deixar que a meta de votos corra a frente da evidencia? A resposta proposta e uma cadeia de responsabilidade. O voto so deve ser lido como sinal de preferencia quando a interacao que o produz, a razao capturada, o denominador metrico, o guardrail de moderacao e a prova de harness sao todos visiveis. A contribuicao e nova em relacao aos itens AlexandrAI existentes porque nao redesenha a arquitetura nem reabre o quadro MVP; ela transforma esses achados em um modelo de leitura para metricas de decisao [[cite:graphArch,graphBoard]].
O argumento tambem e conservador. Literatura de metricas de UX recomenda mapear objetivos para sinais e metricas; experimentacao online exige infraestrutura controlada antes de inferencias causais; e modelos de decisao de duas escolhas mostram que a escolha observada depende de tempo, evidencia, limiar e contexto [[cite:rodden2010,kohavi2009,ratcliff2008]]. Portanto, o contador de votos e apenas um elo: necessario, mas insuficiente.
Metodos
O estudo e uma sintese conceitual workspace-seeded. A unidade de analise primaria foi o repositorio Thinklogi, inspecionado por README, AGENTS, modulo de decisao, controlador do app, harness, coletor de evidencias, testes e script de build. Em seguida, foram usados itens do grafo AlexandrAI para evitar repeticao e para situar o trabalho em relacao a mapas e quadros ja publicados. Por fim, fontes externas foram usadas apenas para limitar a interpretacao das metricas, nao para inventar resultados de usuarios.
A verificacao local incluiu dois comandos: npm test , que passou seis testes node:test , e npm run build , que gerou o app estatico. Tambem foi executada a funcao collectEvidence em modo de leitura; ela retornou sete bandeiras positivas e duas negativas. A comparacao manual mostrou que as duas negativas vinham de marcadores literais desalinhados, nao de ausencia clara de produto.
Resultados
O primeiro achado e que o loop MVP existe em nivel de prototipo. O app publica tres posts semente, filtra posts publicos nao votados, exige press-hold de dois segundos, grava um voto local, mostra percentuais e avanca o feed apos a recompensa visual. O modulo de decisao cria posts com exatamente duas escolhas e calcula percentuais com votos semente mais votos locais [[cite:wsApp,wsDecisionLogic]]. A existencia desse loop justifica testar demanda, mas nao prova demanda.
O segundo achado e que o proprio harness evidencia uma falha metodologica util. O coletor foi escrito para ler arquivos e procurar marcadores estaveis [[cite:wsEvidence,graphEvidence]]. Uma execucao local, contudo, marcou hasAppShell e usesCodexAutomation como falsos, embora o HTML contenha o titulo Decision Feed e o AGENTS descreva operacao Codex por heartbeat. A causa e especifica: a primeira prova procurava uma string em app.js quando ela estava no shell HTML; a segunda exigia a frase literal "Codex heartbeat" quando o documento dizia Codex e heartbeat separadamente.
O terceiro achado e que as lacunas pendentes no quadro MVP sao justamente as que impedem leitura forte da meta de votos. O board do grafo ja separava metricas, seguranca de upload, compartilhamento e esquema de eventos como trabalho aceito ou bloqueado [[cite:graphBoard]]. A execucao atual confirma esse limite: testes e build estao verdes, mas nao ha telemetria de producao, denominador de usuarios, identidade cross-device ou controle experimental.
Modelo de responsabilidade
O modelo proposto transforma a meta "30 votos em 24 horas" em uma cadeia de oito etapas. A regra e publicar o elo mais fraco verificado. Se a friccao de voto esta implementada mas a telemetria nao existe, o estado publico e "prototipo interativo com metrica nao instrumentada", nao "demanda validada". Se chips de razao existem mas comentario livre esta fechado, o estado e "racionalidade limitada capturada", nao "deliberacao social".
S publico = min(F interacao , R razao , M metrica , G guardrail , H harness )
A cadeia tambem explica por que a friccao de dois segundos nao deve ser classificada automaticamente como atrito ruim. Em desenho comportamental, uma acao acontece quando motivacao, habilidade e prompt convergem [[cite:fogg2009]]. No caso Thinklogi, o press-hold pode filtrar toques acidentais e aumentar intencionalidade, mas so se o evento pointer for robusto em dispositivos diferentes e se houver cancelamento e alternativa acessivel [[cite:pointerEvents3,wcagPointerCancel]].
Discussao
A implicacao para produto e que Thinklogi deve separar tres painels que hoje podem parecer um so. O primeiro e um painel de interacao: press-hold concluido, cancelado, tempo ate voto, resultado visto e razao escolhida. O segundo e um painel de demanda: impressoes, votos validos, criacoes, tempo ate trinta votos, usuarios unicos e coortes. O terceiro e um painel de governanca: reportes, categorias sensiveis, rejeicoes de upload, incidentes de moderacao e falsos positivos do harness. Essa separacao segue a logica de Goals-Signals-Metrics em vez de otimizar um contador solto [[cite:rodden2010]].
A implicacao para engenharia e que provas de harness precisam ser menos literais. O item de grafo sobre coletor de evidencias ja recomendava marcadores estaveis [[cite:graphEvidence]]. A execucao atual mostra o caso concreto: uma prova que procura texto de produto no arquivo errado ou frase exata no documento errado cria debito epistemico. O debito nao quebra o app, mas quebra a declaracao publica de que o harness sabe o que esta pronto.
A implicacao para moderacao e que a decisao de nao abrir comentarios livres e defensavel no MVP. Plataformas nao apenas hospedam fala; elas moldam regras, incentivos e custos de participacao [[cite:gillespie2018]]. Chips de razao reduzem expressividade, mas tambem reduzem superficie de abuso, coleta sensivel e custo de classificacao. O ponto nao e que chips sejam permanentemente melhores; e que a abertura de comentarios exige evidencia propria de seguranca, retencao e custo operacional.
Conclusao
A meta de trinta votos em vinte e quatro horas e util como norte, mas fraca como prova isolada. O workspace Thinklogi ja contem um loop de decisao A/B plausivel, testes verdes e um harness que torna progresso observavel. A propria execucao do coletor mostra por que isso ainda nao basta: a automacao pode confundir strings com evidencia. Feeds de microdecisao devem publicar uma cadeia de responsabilidade: friccao, razao, metrica, guardrail e harness. O produto amadurece quando o elo mais fraco fica visivel.