Run any Skill in Manus with one click

bdaylist-backend

Stars0

Forks0

UpdatedJune 24, 2026 at 01:03

Use ao implementar ou revisar QUALQUER feature de backend do BdayList no Supabase (Postgres + RLS + Edge Functions). Cobre motor de reserva atômico/idempotente, modelo de dados, contratos de RPC/endpoint, notificações e enriquecimento de link. Invoque para reserva/cancelamento de presente, RSVP, recados, jobs/cron, e quando o frontend precisar do shape correto dos payloads.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

emersonjds

emersonjds/bdaylist

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	bdaylist-backend
description	Use ao implementar ou revisar QUALQUER feature de backend do BdayList no Supabase (Postgres + RLS + Edge Functions). Cobre motor de reserva atômico/idempotente, modelo de dados, contratos de RPC/endpoint, notificações e enriquecimento de link. Invoque para reserva/cancelamento de presente, RSVP, recados, jobs/cron, e quando o frontend precisar do shape correto dos payloads.

Backend do BdayList (Supabase)

Plataforma decidida no ADR: SPA static export + Supabase Cloud (Postgres + RLS + Edge Functions), região sa-east-1. Sem dinheiro no escopo ("presentear" = reservar). Specs completas em docs/backend/.

Onde mora cada coisa

Responsabilidade	Onde
Leitura pública (por token), RSVP, painel do host	cliente `supabase-js` sob RLS / RPC `SECURITY DEFINER`
Reserva / cancelamento (atômico)	Postgres function via RPC, chamada por Edge Function (`service_role`)
E-mail, enrich de link (anti-SSRF), jobs	Edge Functions + `pg_cron`
Segredos (`RESEND_API_KEY`, `service_role`)	só em env de Edge Function — nunca `NEXT_PUBLIC_*`

Regras inegociáveis

Reserva é server-authoritative, atômica, idempotente, anti-TOCTOU. Nunca checar disponibilidade no app e gravar depois. Garantia no banco:
- índice único parcial em reservas ativas (impõe a invariante no schema);
- SELECT ... FOR UPDATE no presente para serializar concorrentes e devolver ALREADY_RESERVED rastreável;
- replay por idempotency_key (UUID v4 do cliente, 1 por form) antes do lock.
- Ver docs/backend/specs/02-motor-de-reserva.md (DDL + função reserve_gift).
Status do presente é derivado das reservas (view/trigger), nunca uma coluna solta que pode dessincronizar.
Presente em grupo = N reservas por cota/slot; a unicidade muda de "uma por presente" para "uma por slot".
Idempotência de e-mail via notification_log + on conflict do nothing.
Enrich de link nunca quebra o cadastro — degrada para manual; allowlist anti-SSRF + redirect:'error' + timeout 3s + sanitização de metadados.
Conexões via pooler (porta 6543), nunca conexão direta do cliente.

Contratos

Endpoints/RPCs e envelope de erro em docs/backend/specs/05-contratos-endpoints.md. DTOs espelham src/entities/*/model.ts e os handlers MSW em src/mocks/handlers.ts (snake_case no banco → camelCase no JSON).

Antes de concluir (quality gate)

Reserva concorrente testada: 201 + 409 (sem reserva dupla).
GET /registry/:token não vaza listToken no corpo, nem guests[].email, nem quem reservou quando surprise_mode.
Migrations em supabase/migrations/, idempotentes.
Nenhuma tabela sem RLS (ver skill [[bdaylist-rls-seguranca]]).
Testes nas 3 camadas (unit, integração MSW, E2E Playwright com prints).

Acione o agent back para implementar e dba para decisões de schema/índices/concorrência.

More from this repository

same repository

bdaylist-rls-seguranca

emersonjds/bdaylist

Use ao criar/alterar tabelas, policies RLS, Edge Functions ou qualquer superfície que toque PII de convidados, token de compartilhamento, ou enriquecimento de link no BdayList. Garante RLS fail-closed, privacidade da opção "surpresa", anti-SSRF/XSS e conformidade LGPD (dados em São Paulo). Invoque antes de mergear qualquer mudança de schema ou de autorização.

2026-06-240

bluespec-specialize

emersonjds/bdaylist

Specialize Blue Spec in a specific security area, from a source or topic you give it. It reads the material and distills it into a focused, defense-only sub-skill, shaped exactly like the built-in ones, so `/bluespec.skills` loads it afterwards like any other. It only audits and explains — it never writes attack inputs or exploits, and it never touches your code.

2026-06-200

bluespec-charter

emersonjds/bdaylist

Establish or update the project's security charter, the safe-by-default principles every later Blue Spec phase must respect. Proposes a charter when run with no input, or follows the input when given.

2026-06-200

bluespec-detect

emersonjds/bdaylist

Detect what the system actually does by reading the code, and map the security-relevant findings (login, uploads, payments, data exposure, and so on) with the evidence later phases need. Scans the whole project, specific files, or a focused scope, depending on the input.

2026-06-200

bluespec-harden

emersonjds/bdaylist

Apply the defense plan's fixes to the code, safely and one at a time, then record what was applied and what is left. Reads the defense plan and the charter, then hardens every fix, just the fixes, files, or directories you name, or the priorities you choose.

2026-06-200

bluespec-list

emersonjds/bdaylist

List the findings Blue Spec is tracking, by name. It reads `.bluespec/tracking.json` through a hook and prints each tracked finding's name. It has no dependency on any phase and changes nothing, it only reads and reports. If nothing is tracked yet, it says so.

2026-06-200

name	bdaylist-backend
description	Use ao implementar ou revisar QUALQUER feature de backend do BdayList no Supabase (Postgres + RLS + Edge Functions). Cobre motor de reserva atômico/idempotente, modelo de dados, contratos de RPC/endpoint, notificações e enriquecimento de link. Invoque para reserva/cancelamento de presente, RSVP, recados, jobs/cron, e quando o frontend precisar do shape correto dos payloads.

Backend do BdayList (Supabase)

Onde mora cada coisa

Responsabilidade	Onde
Leitura pública (por token), RSVP, painel do host	cliente `supabase-js` sob RLS / RPC `SECURITY DEFINER`
Reserva / cancelamento (atômico)	Postgres function via RPC, chamada por Edge Function (`service_role`)
E-mail, enrich de link (anti-SSRF), jobs	Edge Functions + `pg_cron`
Segredos (`RESEND_API_KEY`, `service_role`)	só em env de Edge Function — nunca `NEXT_PUBLIC_*`

Regras inegociáveis

Reserva é server-authoritative, atômica, idempotente, anti-TOCTOU. Nunca checar disponibilidade no app e gravar depois. Garantia no banco:
- índice único parcial em reservas ativas (impõe a invariante no schema);
- SELECT ... FOR UPDATE no presente para serializar concorrentes e devolver ALREADY_RESERVED rastreável;
- replay por idempotency_key (UUID v4 do cliente, 1 por form) antes do lock.
- Ver docs/backend/specs/02-motor-de-reserva.md (DDL + função reserve_gift).
Status do presente é derivado das reservas (view/trigger), nunca uma coluna solta que pode dessincronizar.
Presente em grupo = N reservas por cota/slot; a unicidade muda de "uma por presente" para "uma por slot".
Idempotência de e-mail via notification_log + on conflict do nothing.
Enrich de link nunca quebra o cadastro — degrada para manual; allowlist anti-SSRF + redirect:'error' + timeout 3s + sanitização de metadados.
Conexões via pooler (porta 6543), nunca conexão direta do cliente.

Contratos

Antes de concluir (quality gate)

Reserva concorrente testada: 201 + 409 (sem reserva dupla).
GET /registry/:token não vaza listToken no corpo, nem guests[].email, nem quem reservou quando surprise_mode.
Migrations em supabase/migrations/, idempotentes.
Nenhuma tabela sem RLS (ver skill [[bdaylist-rls-seguranca]]).
Testes nas 3 camadas (unit, integração MSW, E2E Playwright com prints).

Acione o agent back para implementar e dba para decisões de schema/índices/concorrência.