Back to board
tasksGeneralTo doTask report

Build reusable multi-board Task Board Engine

Architecture / Multi-board engine / Markdown tasks / Vercel

Task metadata

tasks
Cadu
General
8 hours
chat
Created May 7, 2026
Updated May 7, 2026

Original request

"Centralizar os três task boards (regular-task-board, tasks e prosperity-works) em um novo engine reutilizável, mantendo o layout atual que eu gosto, mas separando código-fonte compartilhado, conteúdo por projeto, tema visual por projeto e arquivos de agente. A ideia é não precisar copiar melhorias de componente e markdown entre três ou mais repositórios. Também quero que o markdown das tasks aceite blocos de prompt com botão de copy-to-clipboard, como já acontece nos reports."

Structured task

Problem

Hoje existem três repositórios muito parecidos funcionando como task boards independentes. Isso cria drift: uma melhoria feita em um board precisa ser copiada manualmente para os outros. Recentemente, ao replicar os ícones de highlight/hide nos report cards, um CSS acabou sendo colado dentro dele mesmo em outro repo, causando hover displacement e ícones quebrados.

Se o sistema continuar como cópia por repositório, cada nova melhoria visual, comportamento de markdown, componente ou ajuste de Vercel terá que ser repetido em todos os boards. Com quatro ou mais boards, isso vira um fluxo frágil e difícil de manter.

Context

Os boards atuais são:

  • regular-task-board
  • tasks
  • prosperity-works

Eles compartilham a mesma ideia de app: tarefas em markdown/JSON, reports em markdown, cards com layout parecido, task reports vinculados por slug, e deploy no Vercel.

O layout atual deve ser preservado. Cada projeto pode ter suas próprias cores e tema, mas os componentes React compartilhados não devem ser duplicados por projeto.

A solução desejada é um novo repositório engine, por exemplo task-board-engine ou regular-task-board-engine, com um app Next.js canônico e múltiplos boards selecionados por config/env.

Expected

Criar um novo engine reutilizável com separação clara entre:

shared engine code = componentes, rotas, markdown renderer, cards, layout
board content      = tasks, reports, arquivos de agente
board theme        = CSS variables / tema visual por board
board config       = nome, descrição, source repos, paths, labels

Estrutura sugerida:

task-board-engine/
  app/
  src/
    components/
      tasks/
      reports/
      markdown/
      layout/
    lib/
      boards/
      tasks/
      reports/
      markdown/
    styles/
      globals.css
      themes/
        regular-punks.css
        tasks.css
        prosperity-works.css
  boards/
    regular-punks/
      board.config.ts
      tasks.json ou tasks/
      reports/
      agent-files/
    tasks/
      board.config.ts
      tasks.json ou tasks/
      reports/
      agent-files/
    prosperity-works/
      board.config.ts
      tasks.json ou tasks/
      reports/
      agent-files/

Implementar seleção de board por env var:

NEXT_PUBLIC_BOARD_ID=regular-punks
NEXT_PUBLIC_BOARD_ID=tasks
NEXT_PUBLIC_BOARD_ID=prosperity-works

ou BOARD_ID, se for melhor server-side.

Preservar:

  • layout atual dos cards;
  • comportamento de highlight/hide;
  • Star, EyeOff e Eye;
  • persistência em localStorage, mas com chave escopada por board;
  • reports markdown;
  • task reports vinculados por frontmatter;
  • deploy no Vercel.

Adicionar:

  • markdown renderer compartilhado para reports e tasks;
  • suporte a blocos de prompt/copiar também em páginas de task, não só reports;
  • documentação de como adicionar novo board;
  • documentação de como criar tema;
  • documentação de como fazer deploy de cada board no Vercel;
  • documentação para agentes entenderem onde mexer.

Notes

  • Usar regular-task-board como referência principal de UI/UX.
  • Inspecionar também tasks e prosperity-works antes da migração.
  • Não redesenhar o app.
  • Não criar três versões de TaskCard ou ReportCard.
  • Não hardcodar um board dentro de componentes compartilhados.
  • Cada board pode manter seu tema visual via CSS variables.
  • O Vercel deve poder ter vários projetos apontando para o mesmo repo engine, mudando só a env var do board.
  • Depois que o engine estiver validado, os repos antigos podem ficar como arquivo/cópia de segurança.