Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

bdaylist-backend

Estrelas0

Forks0

Atualizado24 de junho de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

emersonjds

emersonjds/bdaylist

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·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.

Mais deste repositório

mesmo repositório

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.