PDR: Diaum Mission Control — Plano Completo de Implementacao

# PDR — Diaum Mission Control Dashboard

**Product Design Requirements — Documento de Planejamento Completo**

> Dashboard estilo Mission Control para o time Diaum. Painel centralizado de gestao de tarefas, visibilidade do time, metricas de performance e redes sociais.

> **INSTRUCOES PARA O MODELO:**
> 1. **Antes de implementar:** Leia o `CLAUDE.md` e o `ROADMAP.md` na raiz do projeto para contexto completo e status atual.
> 2. **Ao concluir:** Atualize o `ROADMAP.md` (marque checkboxes) e esta issue (se a implementacao mudou algo do plano). Mantenha a documentacao sincronizada.

---

## 1. Visao Geral

### 1.1 Problema
- O time (3 devs) nao tem visibilidade clara do que cada pessoa esta fazendo
- Jira e pesado e burocratico para um time pequeno
- Nao existe um lugar centralizado para acompanhar tarefas, progresso e metricas
- Metricas de redes sociais estao espalhadas entre plataformas

### 1.2 Solucao
Um dashboard interno ("Mission Control") onde o time pode:
- Ver e gerenciar tarefas com autonomia
- Saber o que cada dev esta fazendo em tempo real
- Acompanhar metricas de performance do time
- Monitorar redes sociais do Diaum
- Usar IA (Claude) como assistente de gestao

### 1.3 Usuarios
| Nome | Role | Acesso |
|------|------|--------|
| Horacio | Admin | Acesso total |
| Pedro | Dev | Tarefas, codigo, visao do time |
| Gabriel | Dev | Tarefas, codigo, visao do time |
| Futuros colaboradores | Variavel | Definido pelo admin |

---

## 2. Stack Tecnologica

| Camada | Tecnologia | Justificativa |
|--------|-----------|---------------|
| Framework | Next.js 15 (App Router) | SSR, API routes, mesmo ecossistema do time |
| Frontend | React 19 + TypeScript | Type safety, componentes modernos |
| Styling | Tailwind CSS v4 | Produtividade, consistencia visual |
| Backend/DB | Supabase (PostgreSQL managed) | Auth + DB + Realtime + RLS pronto, free tier generoso |
| ORM/Client | @supabase/supabase-js + @supabase/ssr | Client SDK para Next.js App Router |
| Autenticacao | Supabase Auth | Email/senha, rate limiting nativo, roles via user_metadata |
| API externa | GitHub API (Octokit) | Issues, PRs, commits |
| API externa | Anthropic SDK | Claude como assistente de gestao |
| API externa | APIs de redes sociais | Instagram, TikTok, Twitter/X, YouTube |
| Deploy | Vercel (frontend) + Supabase (backend) | Zero infra, sem VPS necessaria |
| Charts | Recharts | Leve, React-native, boa DX |
| Realtime | Supabase Realtime | Feed de atividade ao vivo sem WebSocket manual |

---

## 3. Arquitetura do Sistema

### 3.1 Estrutura de Pastas

```
diaum-dashboard/
├── supabase/
│   ├── migrations/            # SQL migrations versionadas
│   │   └── 001_initial.sql    # Schema inicial
│   └── seed.sql               # Seed do admin inicial
├── src/
│   ├── app/
│   │   ├── (dashboard)/       # Paginas protegidas
│   │   │   ├── home/          # Dashboard principal
│   │   │   ├── tasks/         # Kanban de tarefas
│   │   │   ├── team/          # Visao do time
│   │   │   ├── performance/   # Metricas de performance
│   │   │   ├── social/        # Redes sociais
│   │   │   ├── calendar/      # Calendario
│   │   │   └── settings/      # Configuracoes e usuarios
│   │   ├── api/
│   │   │   ├── tasks/         # CRUD de tarefas
│   │   │   ├── users/         # Gestao de usuarios (admin)
│   │   │   ├── github/        # Proxy GitHub API
│   │   │   ├── social/        # Proxy APIs sociais
│   │   │   ├── performance/   # Metricas calculadas
│   │   │   ├── webhooks/      # GitHub webhook receiver
│   │   │   └── ai/            # Endpoint Claude API
│   │   ├── auth/
│   │   │   ├── login/         # Pagina de login
│   │   │   ├── callback/      # Supabase auth callback
│   │   │   └── confirm/       # Confirmacao de email
│   │   └── login/             # Pagina de login
│   ├── components/
│   │   ├── layout/            # Sidebar, TopBar, Shell
│   │   ├── tasks/             # TaskCard, KanbanBoard, TaskModal
│   │   ├── team/              # MemberCard, ActivityFeed
│   │   ├── charts/            # Graficos reutilizaveis
│   │   ├── social/            # SocialMetricCard, PostCalendar
│   │   └── ui/                # Botoes, inputs, modais genericos
│   ├── lib/
│   │   ├── supabase/
│   │   │   ├── client.ts      # Supabase browser client
│   │   │   ├── server.ts      # Supabase server client (SSR)
│   │   │   └── admin.ts       # Supabase service role client (criar usuarios)
│   │   ├── github.ts          # Helper GitHub API
│   │   ├── anthropic.ts       # Helper Claude API
│   │   ├── social/            # Helpers por rede social
│   │   ├── permissions.ts     # Logica de roles e acesso
│   │   └── performance.ts     # Calculo de metricas
│   ├── middleware.ts           # Supabase auth middleware (protege rotas)
│   └── types/
│       ├── database.ts        # Types gerados do Supabase (npx supabase gen types)
│       └── index.ts           # Types globais
├── .env.local                 # Secrets (gitignored)
├── next.config.ts
├── tailwind.config.ts
├── tsconfig.json
└── package.json
```

### 3.2 Modelo de Dados (Supabase PostgreSQL)

**Importante:** Supabase Auth gerencia os usuarios em `auth.users`. A tabela `profiles` extende esses dados com informacoes do dashboard.

#### O que persiste no Supabase vs o que vem de APIs externas

**Persiste (Supabase):**
| Dado | Tabela | Por que |
|------|--------|---------|
| Perfil dos usuarios | `profiles` | Roles, avatar, GitHub username |
| Tasks | `tasks` | Core do sistema, historico completo |
| Historico de mudancas | `task_history` | Medir performance, tempo por status |
| Atividade do time | `activities` | Feed, auditoria, metricas |
| Labels | `labels` + `task_labels` | Categorizar tasks |
| Posts agendados | `scheduled_posts` | Calendario de conteudo social |
| Configuracoes | `settings` | Repos ativos, preferencias |

**NAO persiste (vem de APIs em tempo real):**
| Dado | Fonte | Por que nao guardar |
|------|-------|-------------------|
| Issues/PRs do GitHub | GitHub API | Seria duplicacao, GitHub e a fonte da verdade |
| Commits por pessoa | GitHub API | Consulta sob demanda |
| Seguidores/engajamento | APIs sociais | Muda constantemente |
| Lista de repos da org | GitHub API | Descoberta automatica |

#### Schema SQL (migration inicial)

```sql
-- ============================================
-- PROFILES (estende auth.users do Supabase)
-- ============================================
create table profiles (
  id uuid primary key references auth.users(id) on delete cascade,
  name text not null,
  email text not null unique,
  role text not null default 'dev' check (role in ('admin', 'dev')),
  avatar_url text,
  github_username text,          -- para sync de assignee com GitHub
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now()
);

-- Trigger para criar profile automaticamente quando usuario e criado no Supabase Auth
create or replace function handle_new_user()
returns trigger as $$
begin
  insert into profiles (id, name, email, role)
  values (
    new.id,
    coalesce(new.raw_user_meta_data->>'name', split_part(new.email, '@', 1)),
    new.email,
    coalesce(new.raw_user_meta_data->>'role', 'dev')
  );
  return new;
end;
$$ language plpgsql security definer;

create trigger on_auth_user_created
  after insert on auth.users
  for each row execute function handle_new_user();

-- ============================================
-- TASKS
-- ============================================
create type task_status as enum ('todo', 'in_progress', 'in_review', 'done');
create type task_priority as enum ('low', 'medium', 'high', 'urgent');

create table tasks (
  id uuid primary key default gen_random_uuid(),
  title text not null,
  description text,
  status task_status not null default 'todo',
  priority task_priority not null default 'medium',
  github_repo text,              -- "Diaum/diaum-app", "Diaum/diaum-dashboard", etc.
  github_issue int,              -- numero da issue no GitHub
  github_url text,               -- URL direta para abrir no browser
  due_date timestamptz,
  created_at timestamptz not null default now(),
  updated_at timestamptz not null default now(),
  completed_at timestamptz,      -- quando moveu para done (para calcular tempo)

  assignee_id uuid references profiles(id) on delete set null,
  creator_id uuid not null references profiles(id) on delete cascade
);

-- ============================================
-- TASK HISTORY (cada mudanca de status/assignee)
-- Essencial para metricas de performance
-- ============================================
create table task_history (
  id uuid primary key default gen_random_uuid(),
  task_id uuid not null references tasks(id) on delete cascade,
  user_id uuid not null references profiles(id) on delete cascade,
  field text not null,            -- 'status', 'assignee', 'priority'
  old_value text,
  new_value text,
  created_at timestamptz not null default now()
);

-- Exemplo de historico:
-- task "Tela de login"
--   status: null -> todo        (criada em 01/04 por Horacio)
--   assignee: null -> Pedro     (atribuida em 01/04)
--   status: todo -> in_progress (Pedro comecou em 02/04)
--   status: in_progress -> in_review (Pedro enviou pra review em 04/04)
--   status: in_review -> done   (Horacio aprovou em 05/04)
-- Tempo total: 4 dias | Tempo em cada status calculavel

-- ============================================
-- LABELS
-- ============================================
create table labels (
  id uuid primary key default gen_random_uuid(),
  name text not null unique,
  color text not null default '#6366f1'  -- cor hex para o badge
);

create table task_labels (
  task_id uuid references tasks(id) on delete cascade,
  label_id uuid references labels(id) on delete cascade,
  primary key (task_id, label_id)
);

-- ============================================
-- ACTIVITIES (feed do time + auditoria)
-- ============================================
create table activities (
  id uuid primary key default gen_random_uuid(),
  type text not null,             -- 'task_created', 'task_completed', 'task_assigned',
                                  -- 'status_changed', 'comment_added', 'user_login'
  description text not null,      -- "Pedro completou: Tela de login"
  metadata jsonb,                 -- dados extras (ex: {from: "todo", to: "done"})
  created_at timestamptz not null default now(),

  user_id uuid not null references profiles(id) on delete cascade,
  task_id uuid references tasks(id) on delete set null
);

-- ============================================
-- SCHEDULED POSTS (calendario de conteudo)
-- ============================================
create table scheduled_posts (
  id uuid primary key default gen_random_uuid(),
  platform text not null check (platform in ('instagram', 'tiktok', 'twitter', 'youtube')),
  title text not null,
  description text,
  scheduled_for timestamptz not null,
  status text not null default 'scheduled' check (status in ('scheduled', 'published', 'cancelled')),
  created_at timestamptz not null default now(),

  created_by uuid not null references profiles(id) on delete cascade
);

-- ============================================
-- INDEXES (performance)
-- ============================================
create index idx_tasks_status on tasks(status);
create index idx_tasks_assignee on tasks(assignee_id);
create index idx_tasks_creator on tasks(creator_id);
create index idx_tasks_github_repo on tasks(github_repo);
create index idx_task_history_task on task_history(task_id);
create index idx_task_history_created on task_history(created_at);
create index idx_activities_user on activities(user_id);
create index idx_activities_created on activities(created_at);
create index idx_activities_type on activities(type);
create index idx_scheduled_posts_date on scheduled_posts(scheduled_for);

-- ============================================
-- ROW LEVEL SECURITY (RLS)
-- ============================================
alter table profiles enable row level security;
alter table tasks enable row level security;
alter table task_history enable row level security;
alter table activities enable row level security;
alter table labels enable row level security;
alter table task_labels enable row level security;
alter table scheduled_posts enable row level security;

-- Todos os usuarios logados podem ver tudo (time pequeno)
create policy "Users can view all profiles" on profiles for select using (auth.uid() is not null);
create policy "Users can view all tasks" on tasks for select using (auth.uid() is not null);
create policy "Users can view all history" on task_history for select using (auth.uid() is not null);
create policy "Users can view all activities" on activities for select using (auth.uid() is not null);
create policy "Users can view all labels" on labels for select using (auth.uid() is not null);
create policy "Users can view all task_labels" on task_labels for select using (auth.uid() is not null);
create policy "Users can view all posts" on scheduled_posts for select using (auth.uid() is not null);

-- Qualquer usuario logado pode criar/atualizar tasks (mover no kanban, pegar task)
create policy "Users can create tasks" on tasks for insert with check (auth.uid() is not null);
create policy "Users can update tasks" on tasks for update using (auth.uid() is not null);

-- Historico e atividades: qualquer logado pode inserir
create policy "Users can insert history" on task_history for insert with check (auth.uid() is not null);
create policy "Users can insert activities" on activities for insert with check (auth.uid() is not null);

-- Apenas admin pode deletar tasks, gerenciar usuarios, posts
-- (verificado via funcao que checa role no profile)
create or replace function is_admin()
returns boolean as $$
  select role = 'admin' from profiles where id = auth.uid();
$$ language sql security definer;

create policy "Only admin can delete tasks" on tasks for delete using (is_admin());
create policy "Only admin can update profiles" on profiles for update using (is_admin());
create policy "Only admin can manage posts" on scheduled_posts for insert with check (is_admin());
create policy "Only admin can update posts" on scheduled_posts for update using (is_admin());
create policy "Only admin can delete posts" on scheduled_posts for delete using (is_admin());

-- ============================================
-- REALTIME (ativar para feed ao vivo)
-- ============================================
-- No Supabase Dashboard: ativar Realtime para as tabelas:
-- activities, tasks, task_history
-- Isso permite que o feed de atividade atualize em tempo real
-- sem precisar de WebSocket manual
```

#### Dados derivados (calculados a partir do que foi persistido)

Essas metricas NAO precisam de tabela propria — sao queries sobre os dados acima:

```sql
-- Tasks concluidas por pessoa na semana
select p.name, count(*) as tasks_done
from tasks t join profiles p on t.assignee_id = p.id
where t.status = 'done'
  and t.completed_at >= now() - interval '7 days'
group by p.name;

-- Tempo medio por task por pessoa
select p.name,
  avg(extract(epoch from (t.completed_at - t.created_at)) / 3600) as avg_hours
from tasks t join profiles p on t.assignee_id = p.id
where t.status = 'done' and t.completed_at is not null
group by p.name;

-- Tasks travadas (sem mudanca ha mais de 3 dias)
select t.title, p.name as assignee, t.updated_at
from tasks t left join profiles p on t.assignee_id = p.id
where t.status in ('in_progress', 'in_review')
  and t.updated_at < now() - interval '3 days';

-- Streak de dias produtivos por pessoa
-- (dias consecutivos com pelo menos 1 task concluida)
-- Calculado no backend via query + logica em TypeScript
```

---

## 4. Sistema de Autenticacao e Permissoes

### 4.1 Autenticacao (Supabase Auth)
- **Sem cadastro publico** — admin cria usuarios via `supabase.auth.admin.createUser()` (service role key)
- Login via email + senha (Supabase Auth nativo)
- Sessao via cookie gerenciado pelo `@supabase/ssr` (HttpOnly, SameSite=Lax, Secure em producao)
- Rate limiting nativo do Supabase Auth
- Role armazenado em `profiles.role` (nao em JWT custom claims — mais simples de gerenciar)
- Middleware Next.js (`middleware.ts`) valida sessao e redireciona para /login se expirada
- Fluxo de criacao de usuario:
  1. Admin acessa Settings -> Usuarios -> "Criar usuario"
  2. Preenche nome, email, role (admin/dev), GitHub username
  3. Backend usa service role key para criar no Supabase Auth
  4. Trigger automatico cria o profile na tabela `profiles`
  5. Usuario recebe email para definir senha (ou admin define direto)

### 4.2 Roles e Permissoes

| Recurso | ADMIN | DEV |
|---------|-------|-----|
| Dashboard Home | Sim | Sim |
| Ver todas as tasks | Sim | Sim |
| Criar tasks | Sim | Sim |
| Atribuir tasks a outros | Sim | Nao |
| Pegar task livre | Sim | Sim |
| Visao do time | Sim | Sim |
| Metricas de performance | Sim | Nao |
| Redes sociais / analytics | Sim | Nao |
| Gerenciar usuarios | Sim | Nao |
| Configuracoes gerais | Sim | Nao |
| Assistente IA (Claude) | Sim | Sim (limitado) |

### 4.3 Middleware de Protecao
```
- /login -> publico
- /api/auth/* -> publico
- /api/health -> publico
- Tudo mais -> requer sessao valida
- Rotas admin -> requer role ADMIN (retorna 403 se DEV)
```

---

## 5. Funcionalidades por Modulo

### 5.1 Dashboard Home
**Acesso:** Todos

Visao geral ao abrir o dashboard de manha:
- **Minhas tasks** — tasks atribuidas ao usuario logado
- **Atividade recente do time** — feed: "Pedro concluiu X", "Gabriel comecou Y"
- **Tasks livres disponiveis** — sem dono, prontas pra pegar
- **Resumo da semana** — tasks concluidas vs criadas
- **Alertas** — tasks atrasadas, deadlines proximos

### 5.2 Tasks (Kanban) — Multi-repo
**Acesso:** Todos (criar/atribuir a outros: so admin)

- Board Kanban com 4 colunas: **To Do -> In Progress -> In Review -> Done**
- Drag and drop para mover tasks entre colunas
- Cada card mostra: titulo, assignee (avatar), prioridade (cor), labels, deadline, **badge do repo**
- Modal de detalhes: descricao, comentarios, historico de atividade
- Filtros: por assignee, prioridade, label, status, **por repositorio**
- **Clicar no card** -> abre modal com detalhes no dashboard + botao **"Ver no GitHub"** que abre a issue direto no browser

**Multi-repo — Todos os repos da org Diaum:**
- Ao criar task, o admin seleciona o repo de destino (dropdown com todos os repos da org)
- O Kanban exibe tasks de TODOS os repos juntos, com badge colorido indicando o repo
- Filtro rapido por repo: "Mostrar so tasks do diaum-app" / "Mostrar tudo"
- Repos sao descobertos automaticamente via GitHub API (listagem da org Diaum)

**Integracao GitHub Issues (bidirecional):**
- Criar task no dashboard -> cria issue no repo selecionado
- Mover para Done -> fecha a issue automaticamente
- Atribuir pessoa no dashboard -> pessoa aparece como assignee na issue do GitHub
- Remover assignee no dashboard -> remove assignee na issue do GitHub
- Sync reverso via webhook: issue fechada/atribuida no GitHub -> reflete no dashboard
- Cada usuario do dashboard tem seu GitHub username mapeado (GitHubUserMap) para o sync funcionar

### 5.3 Visao do Time
**Acesso:** Todos

- Card por membro: nome, avatar, role, task atual, status (online/offline)
- Lista de tasks de cada pessoa
- Feed de atividade do time (ultimas 24h/7d)
- "Quem ta fazendo o que agora" — visao rapida

### 5.4 Metricas de Performance
**Acesso:** Apenas ADMIN

**Metricas individuais:**
| Metrica | Fonte |
|---------|-------|
| Tasks concluidas (dia/semana/mes) | Sistema de tasks |
| Tempo medio por task | Criacao -> conclusao |
| Tasks em andamento | Tasks com status IN_PROGRESS |
| Streak de dias produtivos | Dias consecutivos com 1+ task concluida |
| PRs abertos e mergeados | GitHub API |
| Commits por periodo | GitHub API |

**Metricas do time:**
- Total de tasks concluidas no periodo
- Distribuicao de carga (quem tem mais tasks)
- Velocity (tasks/semana ao longo do tempo)
- Tasks travadas (sem atualizacao ha X dias)
- Grafico de burndown semanal

**Relatorio com IA (Fase 3):**
- Resumo semanal gerado pelo Claude
- Identificacao de gargalos
- Sugestoes de redistribuicao

### 5.5 Metricas do App Diaum (dados do Supabase do app)
**Acesso:** Apenas ADMIN

Conecta diretamente ao banco Supabase do app Diaum (read-only) para exibir metricas do produto em tempo real.

**Metricas disponiveis:**
| Metrica | Descricao |
|---------|-----------|
| Total de usuarios | Count de usuarios cadastrados |
| Novos usuarios (dia/semana/mes) | Crescimento do app |
| Usuarios ativos | Usuarios com atividade recente |
| Retencao | % de usuarios que voltam (D1, D7, D30) |
| Tendencia de crescimento | Grafico de novos cadastros ao longo do tempo |

**Implementacao:**
- Segundo client Supabase apontando para o projeto do app Diaum
- Usa service role key (read-only, so no server) para acessar dados de `auth.users` e tabelas do app
- Dados consultados sob demanda (nao duplicados no banco do dashboard)
- Card de destaque no Dashboard Home: "Usuarios do Diaum: 1.234 (+23 esta semana)"

**Arquitetura multi-Supabase:**
```
lib/supabase/
├── dashboard.ts    # Client do Supabase do dashboard (read/write)
├── diaum-app.ts    # Client do Supabase do app Diaum (read-only, server-only)
└── server.ts       # Helper para criar clients no server
```

**Seguranca:**
- A service role key do app Diaum NUNCA vai pro browser
- So acessada via Server Components ou API routes
- Queries sao read-only (select), nunca write
- Considerar criar um role read-only no Supabase do app para limitar acesso

### 5.6 Redes Sociais
**Acesso:** Apenas ADMIN

**Plataformas:**
- Instagram (via Instagram Graph API)
- TikTok (via TikTok API)
- Twitter/X (via Twitter API v2)
- YouTube (via YouTube Data API v3)

**Metricas por plataforma:**
| Metrica | IG | TikTok | Twitter | YouTube |
|---------|-----|--------|---------|---------|
| Seguidores | Sim | Sim | Sim | Sim (inscritos) |
| Crescimento | Sim | Sim | Sim | Sim |
| Engajamento | Sim | Sim | Sim | Sim |
| Impressoes/Views | Sim | Sim | Sim | Sim |
| Posts recentes | Sim | Sim | Sim | Sim (videos) |

**Calendario de conteudo:**
- Visao semanal/mensal de posts agendados
- Criar/editar posts no calendario
- Marcar como publicado

### 5.7 Calendario
**Acesso:** Todos

- Visao mensal e semanal
- Eventos: deadlines de tasks, posts agendados, datas importantes
- Color-coded por tipo (task, social, reuniao)
- Criar eventos rapidos

### 5.8 Assistente IA (Claude)
**Acesso:** Todos (funcionalidades admin-only marcadas)

**Para todos:**
- Chat com Claude no contexto do projeto
- "Quebra essa feature em subtasks"
- "Explica o que essa task envolve tecnicamente"

**Para admin:**
- "Gera tasks para implementar a tela X"
- "Resume o que o time fez essa semana"
- "Analisa a performance do Gabriel esse mes"
- Relatorio semanal automatico

**Implementacao:**
- Rota /api/ai/chat que chama Anthropic SDK
- System prompt com contexto do projeto Diaum
- Acesso a dados de tasks e performance para gerar relatorios

### 5.9 Configuracoes
**Acesso:** Apenas ADMIN

- **Usuarios:** Criar, editar, desativar usuarios
- **Roles:** Atribuir ADMIN ou DEV
- **Integracoes:** Configurar tokens das APIs (GitHub, sociais)
- **Projeto:** Nome, descricao, repos conectados

---

## 6. Integracoes Externas

### 6.1 GitHub API — Multi-repo (Org Diaum)
**Objetivo:** Sincronizar tasks com issues de TODOS os repos da org Diaum

- **Auth:** GitHub App (recomendado) ou Personal Access Token com scope `repo` e `org:read`
- **Escopo:** Org inteira — `https://api.github.com/orgs/Diaum/repos` lista todos os repos
- **Funcionalidades:**
  - Listar todos os repos da org (publicos + privados)
  - Criar issue no repo selecionado ao criar task
  - Fechar issue ao concluir task
  - Atribuir/remover assignee na issue ao atribuir/remover no dashboard
  - Listar PRs e commits por membro (cross-repo)
  - Webhook para sync reverso (issue fechada/assignada no GitHub -> reflete no dashboard)
  - Mapeamento usuario dashboard <-> GitHub username (GitHubUserMap)
  - Link direto: cada task tem URL da issue para abrir no browser

### 6.2 Supabase do App Diaum (cross-project)
**Objetivo:** Ler metricas do produto em tempo real direto do banco do app

- **Auth:** Service role key do projeto Supabase do app Diaum
- **Acesso:** Read-only, server-side only (nunca exposto no browser)
- **Dados consumidos:**
  - `auth.users` — total de usuarios, novos cadastros por periodo
  - Tabelas de tracking do app — sessoes, atividade, metricas de uso
- **Seguranca:** Considerar criar um database role read-only especifico ou usar views/functions no Supabase do app que exponham so os aggregates necessarios (ex: `get_user_count()`, `get_daily_signups()`)
- **Nota:** Se o schema do app Diaum mudar, as queries do dashboard precisam ser atualizadas. Manter documentado quais tabelas/colunas o dashboard consome.

### 6.3 APIs de Redes Sociais
| Plataforma | API | Auth | Observacoes |
|-----------|-----|------|-------------|
| Instagram | Graph API v21 | OAuth + Facebook Business | Requer Facebook App e pagina conectada |
| TikTok | TikTok API | OAuth | Requer app aprovado |
| Twitter/X | API v2 | OAuth 2.0 | Plano Basic ($100/mes) ou Free (limitado) |
| YouTube | Data API v3 | API Key + OAuth | Quota de 10k unidades/dia |

### 6.4 Anthropic API (Claude)
- **SDK:** @anthropic-ai/sdk
- **Modelo:** Claude Sonnet 4.6 (custo-beneficio para uso diario)
- **Rate limiting:** Limitar requests por usuario por dia
- **Custo estimado:** ~$5-15/mes para uso do time

---

## 7. Fases de Implementacao

### Fase 1 — MVP (Fundacao)
**Objetivo:** Substituir o Jira e ter visibilidade do time

**Duracaoo estimada:** 2-3 semanas

- [x] Setup do projeto (Next.js 15, Supabase, Tailwind)
- [x] Setup Supabase (projeto, migration inicial, RLS policies)
- [x] Sistema de autenticacao (Supabase Auth, login, middleware, roles)
- [x] CRUD de usuarios (admin cria contas)
- [x] Layout: Sidebar + TopBar + Shell
- [x] Sistema de tasks com Kanban multi-repo (drag and drop)
- [x] Integracao GitHub Issues multi-repo (criar/fechar/assignee sync)
- [x] Mapeamento usuario <-> GitHub username
- [x] Feed de atividade do time
- [x] Dashboard Home (minhas tasks, atividade recente)
- [x] Deploy inicial

**Entregavel:** Time comeca a usar no dia a dia, abandona o Jira.

### Fase 2 — Visibilidade e Metricas
**Objetivo:** Medir performance e acompanhar redes sociais

- [x] Metricas de performance individual e do time
- [x] Graficos (velocity, burndown, distribuicao de carga)
- [x] Integracao GitHub (PRs, commits por membro)
- [x] Metricas do App Diaum (integracao com Supabase do app, usuarios, retencao)
- [ ] Dashboard de redes sociais (Instagram, TikTok, Twitter, YouTube)
- [ ] Calendario de conteudo
- [ ] Calendario geral (tasks + posts + eventos)
- [x] Notificacoes (tasks atribuidas, deadlines, etc.)

**Entregavel:** Admin tem visao completa do time e das redes sociais.

### Fase 3 — Inteligencia
**Objetivo:** IA como assistente de gestao

- [ ] Integracao Claude API (chat contextual)
- [ ] Geracao automatica de tasks via IA
- [ ] Relatorio semanal de performance (gerado por IA)
- [ ] Analise de gargalos e sugestoes
- [ ] Code review assistido (diff do PR -> analise do Claude)
- [ ] Sugestoes de redistribuicao de carga

**Entregavel:** Dashboard inteligente que ajuda ativamente na gestao.

---

## 8. Variaveis de Ambiente

```env
# Supabase
NEXT_PUBLIC_SUPABASE_URL="https://xxxxx.supabase.co"
NEXT_PUBLIC_SUPABASE_ANON_KEY="eyJ..."      # chave publica (usada no browser, protegida por RLS)
SUPABASE_SERVICE_ROLE_KEY="eyJ..."           # chave privada (so no server, para criar usuarios)

# Supabase — App Diaum (read-only, para metricas do produto)
DIAUM_APP_SUPABASE_URL="https://yyyyy.supabase.co"
DIAUM_APP_SUPABASE_SERVICE_KEY="eyJ..."      # service key do projeto do app (so no server, read-only)

# GitHub
GITHUB_TOKEN="ghp_..."
GITHUB_ORG="Diaum"
# Nao precisa de GITHUB_REPO — o dashboard lista todos os repos da org automaticamente

# Anthropic
ANTHROPIC_API_KEY="sk-ant-..."

# Redes Sociais
INSTAGRAM_ACCESS_TOKEN="..."
TIKTOK_ACCESS_TOKEN="..."
TWITTER_BEARER_TOKEN="..."
YOUTUBE_API_KEY="..."
```

**Nota:** Nao precisa de `ADMIN_EMAIL`/`ADMIN_PASSWORD` como env var. O admin inicial e criado via Supabase Dashboard ou via seed SQL no primeiro deploy.

---

## 9. Design e UX

### 9.1 Principios
- **Informacao na hora certa** — abrir o dashboard e saber o que fazer
- **Minimo de cliques** — pegar task, mudar status, ver o time = rapido
- **Sem burocracia** — o Jira morreu por ser pesado, isso aqui tem que ser leve
- **Mobile-ready no futuro** — mas por agora, foco em desktop

### 9.2 Layout Principal
```
+--------------------------------------------------+
|  TopBar: Logo Diaum | Busca | Notificacoes | User |
+--------+-----------------------------------------+
|        |                                         |
| Side   |                                         |
| bar    |          Conteudo Principal              |
|        |                                         |
| Home   |                                         |
| Tasks  |                                         |
| Time   |                                         |
| Perf   |        (varia por pagina)               |
| Social |                                         |
| Cal    |                                         |
| IA     |                                         |
| Config |                                         |
|        |                                         |
+--------+-----------------------------------------+
```

### 9.3 Tema Visual
- Dark mode como padrao (devs preferem)
- Cores da marca Diaum
- Tipografia clean e legivel
- Icones: Lucide React

---

## 10. Seguranca

- Senhas gerenciadas pelo Supabase Auth (bcrypt automatico)
- Sessoes via cookie gerenciado por `@supabase/ssr` (HttpOnly + SameSite + Secure)
- Rate limiting nativo do Supabase Auth em login
- Row Level Security (RLS) no banco — mesmo que o frontend seja comprometido, o banco protege os dados
- `SUPABASE_SERVICE_ROLE_KEY` nunca exposta no browser (so em Server Components / API routes)
- `NEXT_PUBLIC_SUPABASE_ANON_KEY` e segura porque RLS garante que usuarios so acessam o que podem
- CORS restrito em producao
- Tokens de API em variaveis de ambiente (.env.local)
- Sem cadastro publico — apenas admin cria usuarios via service role
- Logs de acesso e atividade (tabela `activities`)
- Middleware Next.js (`middleware.ts`) protege todas as rotas do dashboard
- Funcao `is_admin()` no banco valida role em policies RLS

---

## 11. Criterios de Sucesso

| Criterio | Meta |
|----------|------|
| Time usando diariamente | 100% do time em 1 semana apos deploy |
| Jira descontinuado | Migracao completa em 2 semanas |
| Tempo para saber "quem faz o que" | < 5 segundos (abrir dashboard) |
| Criar e atribuir task | < 30 segundos |
| Visibilidade das redes sociais | Todas as 4 plataformas num lugar so |

---

## Referencias

- **Repositorio:** https://github.com/Diaum/diaum-dashboard
- **Organizacao:** https://github.com/Diaum
- **App Diaum:** Repo privado na org Diaum (React Native)

---

*Documento criado em 2026-04-10 por Horacio com assistencia do Claude.*
*Este PDR e um documento vivo e sera atualizado conforme o projeto evolui.*
















Nome	Role	Acesso
Horacio	Admin	Acesso total
Pedro	Dev	Tarefas, codigo, visao do time
Gabriel	Dev	Tarefas, codigo, visao do time
Futuros colaboradores	Variavel	Definido pelo admin

Camada	Tecnologia	Justificativa
Framework	Next.js 15 (App Router)	SSR, API routes, mesmo ecossistema do time
Frontend	React 19 + TypeScript	Type safety, componentes modernos
Styling	Tailwind CSS v4	Produtividade, consistencia visual
Backend/DB	Supabase (PostgreSQL managed)	Auth + DB + Realtime + RLS pronto, free tier generoso
ORM/Client	@supabase/supabase-js + @supabase/ssr	Client SDK para Next.js App Router
Autenticacao	Supabase Auth	Email/senha, rate limiting nativo, roles via user_metadata
API externa	GitHub API (Octokit)	Issues, PRs, commits
API externa	Anthropic SDK	Claude como assistente de gestao
API externa	APIs de redes sociais	Instagram, TikTok, Twitter/X, YouTube
Deploy	Vercel (frontend) + Supabase (backend)	Zero infra, sem VPS necessaria
Charts	Recharts	Leve, React-native, boa DX
Realtime	Supabase Realtime	Feed de atividade ao vivo sem WebSocket manual

Dado	Tabela	Por que
Perfil dos usuarios	`profiles`	Roles, avatar, GitHub username
Tasks	`tasks`	Core do sistema, historico completo
Historico de mudancas	`task_history`	Medir performance, tempo por status
Atividade do time	`activities`	Feed, auditoria, metricas
Labels	`labels` + `task_labels`	Categorizar tasks
Posts agendados	`scheduled_posts`	Calendario de conteudo social
Configuracoes	`settings`	Repos ativos, preferencias

Dado	Fonte	Por que nao guardar
Issues/PRs do GitHub	GitHub API	Seria duplicacao, GitHub e a fonte da verdade
Commits por pessoa	GitHub API	Consulta sob demanda
Seguidores/engajamento	APIs sociais	Muda constantemente
Lista de repos da org	GitHub API	Descoberta automatica

Recurso	ADMIN	DEV
Dashboard Home	Sim	Sim
Ver todas as tasks	Sim	Sim
Criar tasks	Sim	Sim
Atribuir tasks a outros	Sim	Nao
Pegar task livre	Sim	Sim
Visao do time	Sim	Sim
Metricas de performance	Sim	Nao
Redes sociais / analytics	Sim	Nao
Gerenciar usuarios	Sim	Nao
Configuracoes gerais	Sim	Nao
Assistente IA (Claude)	Sim	Sim (limitado)

Metrica	Fonte
Tasks concluidas (dia/semana/mes)	Sistema de tasks
Tempo medio por task	Criacao -> conclusao
Tasks em andamento	Tasks com status IN_PROGRESS
Streak de dias produtivos	Dias consecutivos com 1+ task concluida
PRs abertos e mergeados	GitHub API
Commits por periodo	GitHub API

Metrica	Descricao
Total de usuarios	Count de usuarios cadastrados
Novos usuarios (dia/semana/mes)	Crescimento do app
Usuarios ativos	Usuarios com atividade recente
Retencao	% de usuarios que voltam (D1, D7, D30)
Tendencia de crescimento	Grafico de novos cadastros ao longo do tempo

Metrica	IG	TikTok	Twitter	YouTube
Seguidores	Sim	Sim	Sim	Sim (inscritos)
Crescimento	Sim	Sim	Sim	Sim
Engajamento	Sim	Sim	Sim	Sim
Impressoes/Views	Sim	Sim	Sim	Sim
Posts recentes	Sim	Sim	Sim	Sim (videos)

Plataforma	API	Auth	Observacoes
Instagram	Graph API v21	OAuth + Facebook Business	Requer Facebook App e pagina conectada
TikTok	TikTok API	OAuth	Requer app aprovado
Twitter/X	API v2	OAuth 2.0	Plano Basic ($100/mes) ou Free (limitado)
YouTube	Data API v3	API Key + OAuth	Quota de 10k unidades/dia

Criterio	Meta
Time usando diariamente	100% do time em 1 semana apos deploy
Jira descontinuado	Migracao completa em 2 semanas
Tempo para saber "quem faz o que"	< 5 segundos (abrir dashboard)
Criar e atribuir task	< 30 segundos
Visibilidade das redes sociais	Todas as 4 plataformas num lugar so

Uh oh!

PDR: Diaum Mission Control — Plano Completo de Implementacao #1

Description

PDR — Diaum Mission Control Dashboard

1. Visao Geral

1.1 Problema

1.2 Solucao

1.3 Usuarios

2. Stack Tecnologica

3. Arquitetura do Sistema

3.1 Estrutura de Pastas

3.2 Modelo de Dados (Supabase PostgreSQL)

O que persiste no Supabase vs o que vem de APIs externas

Schema SQL (migration inicial)

Dados derivados (calculados a partir do que foi persistido)

4. Sistema de Autenticacao e Permissoes

4.1 Autenticacao (Supabase Auth)

4.2 Roles e Permissoes

4.3 Middleware de Protecao

5. Funcionalidades por Modulo

5.1 Dashboard Home

5.2 Tasks (Kanban) — Multi-repo

5.3 Visao do Time

5.4 Metricas de Performance

5.5 Metricas do App Diaum (dados do Supabase do app)

5.6 Redes Sociais

5.7 Calendario

5.8 Assistente IA (Claude)

5.9 Configuracoes

6. Integracoes Externas

6.1 GitHub API — Multi-repo (Org Diaum)

6.2 Supabase do App Diaum (cross-project)

6.3 APIs de Redes Sociais

6.4 Anthropic API (Claude)

7. Fases de Implementacao

Fase 1 — MVP (Fundacao)

Fase 2 — Visibilidade e Metricas

Fase 3 — Inteligencia

8. Variaveis de Ambiente

9. Design e UX

9.1 Principios

9.2 Layout Principal

9.3 Tema Visual

10. Seguranca

11. Criterios de Sucesso

Referencias

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions