NCAA180-Sleeper
League Data for NCAA 180
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기Aplicação web para se divertir com meus amigos.
저장소 README에서 가져옴
README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Gestão completa de um racha de futebol semanal — presença, fila de suplentes, rateio automático, gols e assistências, ranking mensal com pódio, premiação e caixa transparente.README 전문 보기 ↗
Gestão completa de um racha de futebol semanal — presença, fila de suplentes, rateio automático, gols e assistências, ranking mensal com pódio, premiação e caixa transparente.
Todo grupo que joga uma pelada semanal enfrenta o mesmo caos: confirmação de presença espalhada no WhatsApp, ninguém sabe se sobrou vaga ou virou suplente, alguém sempre esquece de pagar e o saldo do caixa vive incerto. O Resenha F.C resolve isso com um fluxo único: o jogador confirma presença pelo celular, o sistema controla automaticamente titulares/suplentes (2 goleiros + 15 linha), divide o valor da quadra em tempo real entre quem confirmou, registra gols/assistências e fecha um ranking mensal com pódio e premiação — tudo com controle de acesso por papel (administrador, moderador, jogador).
Construído como estudo de caso de uma aplicação multi-tenant de regras de negócio concorrentes (duas pessoas confirmando presença ao mesmo tempo não podem furar a fila) resolvidas no banco, não no frontend.
| Camada | Tecnologia |
|---|---|
| Framework | Next.js 16 (App Router, Server Actions, Server Components) |
| Linguagem | TypeScript (strict) |
| Estilo | Tailwind CSS v4 |
| Banco de dados | PostgreSQL (Supabase) |
| Autenticação | Supabase Auth + RLS |
| Regras de negócio | Funções Postgres SECURITY DEFINER (evitam condição de corrida na fila) |
| Deploy | Vercel + Supabase (free tier) |
| PWA | Web App Manifest + Service Worker |
flowchart LR
subgraph Cliente
A[PWA / Navegador]
end
subgraph Vercel
B[Next.js — Server Components & Actions]
P[proxy.ts — sessão & guarda de rotas por papel]
end
subgraph Supabase
C[(Postgres)]
D[Auth]
E[RPC SECURITY DEFINER\nfila · rateio · ranking]
end
A <--> B
B --> P
B -- RLS por papel --> C
B --> D
B -- confirmar/desistir/finalizar --> E
E --> C
A UI nunca decide sozinha se alguém vira titular ou suplente, nem recalcula o rateio — ela apenas chama funções de banco (confirmar_presenca, desistir_presenca, finalizar_lista, finalizar_ranking) que fazem a leitura e escrita de forma atômica. Isso elimina condição de corrida quando dois jogadores confirmam ao mesmo tempo, e mantém a regra de negócio em um único lugar, reutilizável por qualquer client futuro (app nativo, bot de WhatsApp etc.).
erDiagram
players ||--o| player_attributes : "tem"
players ||--o| profiles : "autentica como"
players ||--o{ match_players : "confirma em"
matches ||--o{ match_players : "lista de"
players ||--o{ ranking_results : "pontua em"
rankings ||--o{ ranking_results : "agrega"
players ||--o{ prizes : "premiado em"
rankings ||--o{ prizes : "gera"
matches ||--o{ cash_transactions : "gera lançamento"
players {
uuid id PK
text apelido
bool eh_goleiro
text classificacao "F..A"
}
matches {
uuid id PK
date data
numeric valor_total
text status "fechada|aberta|finalizada"
}
match_players {
uuid match_id FK
uuid player_id FK
int posicao_lista
text tipo_vaga "titular|suplente"
numeric valor_devido
bool pagou
int gols
int assistencias
}
rankings {
uuid id PK
text periodo "YYYY-MM"
bool finalizado
}
A especificação original deixava alguns pontos de negócio em aberto — decisões tomadas e o porquê:
[email protected], ver lib/auth/roles.ts). O jogador só digita nome/apelido e senha — nunca vê esse detalhe.recalcular_valores) e só é congelado quando a lista fecha — assim quem confirma cedo já vê o valor mais próximo do real.confirmar_presenca/desistir_presenca rodam com SECURITY DEFINER para serem atômicas: a checagem de vaga disponível e a escrita acontecem na mesma transação.lib/business/scoring.ts e classification.ts — ajustar o peso de um gol não exige tocar em nenhuma tela.proxy.ts em vez de middleware.ts. No Next.js 16 o arquivo de middleware foi renomeado para Proxy — a guarda de sessão e RBAC por rota vive em src/proxy.ts.proxy.ts obriga o jogador a criar sua própria senha em /trocar-senha antes de acessar qualquer outra tela.resenha-fc/
├─ src/
│ ├─ app/
│ │ ├─ login/ # autenticação (Server Action)
│ │ └─ (app)/ # rotas autenticadas
│ │ ├─ dashboard/
│ │ ├─ racha/ # fila, confirmação, gols/pagamentos
│ │ ├─ ranking/ # pódio e histórico
│ │ ├─ jogadores/[id]/ # perfil, habilidades, premiações
│ │ ├─ caixa/
│ │ └─ admin/usuarios/ # cadastro de jogadores/moderadores
│ ├─ components/{layout,pwa}/
│ ├─ lib/
│ │ ├─ supabase/{client,server,admin}.ts
│ │ ├─ business/{scoring,classification,racha}.ts
│ │ └─ auth/{roles,session}.ts
│ └─ proxy.ts # sessão + RBAC por rota
├─ supabase/migrations/ # schema, RLS e funções (SQL versionado)
├─ scripts/create-admin.mjs # bootstrap do primeiro administrador
└─ public/{manifest.json,sw.js,icons/}
npm install
cp .env.example .env.local # preencha com as chaves do seu projeto Supabase
npm run dev
supabase/migrations/ em ordem numérica no SQL Editor.Project URL, anon public key e service_role key (Project Settings > API) para .env.local.node --env-file=.env.local scripts/create-admin.mjs "Seu Nome" "seuapelido"
O comando imprime uma senha temporária de 6 dígitos — no primeiro login o app pede pra trocar por uma senha definitiva.http://localhost:3000 e faça login com o apelido e a senha temporária.