MONAILabel
MONAI Label은 지능형 오픈소스 이미지 라벨링 및 학습 도구이다
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
SaaS multi-tenant de atendimento com IA para clínicas médicas e de estética. Uma recepcionista digital que trabalha 24 horas no WhatsApp, agenda, confirma consulta e devolve consulta perdida em dinheiro. Documentação de produto e handoff de engenharia do V1. Abra o Claude Code nesta pasta e cole o conteúdo de PROMPT_INICIAL.md. Ele já diz ao Claude Code o que ler, em que ordem, e qual é a primeira tarefa. Como rodar: o motor roda sozinho (ver supabase/operacao/motor-por-cron.md)README 전문 보기 ↗
SaaS multi-tenant de atendimento com IA para clínicas médicas e de estética. Uma recepcionista digital que trabalha 24 horas no WhatsApp, agenda, confirma consulta e devolve consulta perdida em dinheiro.
Documentação de produto e handoff de engenharia do V1.
Abra o Claude Code nesta pasta e cole o conteúdo de PROMPT_INICIAL.md. Ele já diz ao Claude Code o que ler, em que ordem, e qual é a primeira tarefa.
npm run dev # a aplicação
Em produção a aplicação roda na Vercel (região de São Paulo) e não existe processo de worker em servidor nenhum. O motor de automação roda pelo pg_cron, dentro do Supabase, desde 02/09/2026:
pg_cron chama (via pg_net) a rota POST /api/webhooks/motor na Vercel, que processa a fila de tarefas: envio das réguas de confirmação, pós falta e follow up, o botão "Cobrar agora", o download de mídia que o paciente manda;motor_manutencao() roda no próprio banco: planeja as réguas, limpa as reservas de horário vencidas, expira ofertas da lista de espera;poda-do-cron apaga o histórico do agendador com mais de 7 dias.Com o motor parado a aplicação abre, a agenda funciona e nenhuma mensagem automática sai. Quando isso acontece, o sistema mostra a faixa "as mensagens automáticas estão paradas" no topo de todas as telas, e a rota GET /api/webhooks/saude passa a responder 503 para o monitor externo que avisa o dono por e-mail (configuração no runbook).
npm run worker é o mesmo motor num laço local, na mesma cadência: serve para desenvolver e testar num banco sem pg_cron e como ponte de emergência quando o cron é desligado. Contra o banco de produção, só durante incidente (ver "Desligar" no runbook).
Para conferir que a corrente inteira está funcionando (planejamento, envio, webhook, resposta do paciente, pós falta), com a aplicação e o motor de pé:
npm run prova:motor
Ele cria uma clínica descartável com canal de mentira, exercita o caminho completo contra o banco e o webhook reais, e apaga tudo no fim. Nenhum paciente de verdade é tocado.
O canal WhatsApp precisa de um endereço público estável em PUBLIC_APP_URL: é ele que o provedor chama de volta com as respostas dos pacientes, e ele fica gravado no momento da conexão. Trocar a variável não basta, é preciso reconectar o número. Detalhes em .env.example.
conduzza/
├── CLAUDE.md regras permanentes do projeto, lidas pelo Claude Code em toda sessão
├── PROMPT_INICIAL.md o texto para colar na primeira mensagem
├── .env.example variáveis de ambiente
├── README.md este arquivo
└── docs/
├── 01_spec_funcional_conduzza_clinicas.md spec, escopo V1 e V2, alerta comercial, cronograma
├── 02_brief_telas_claude_design.md 14 telas, paleta validada, componentes e estados
├── 03_arquitetura.md stack, pastas, fluxos, RLS, concorrência de agenda
├── 04_modelo_dados.md schema SQL de referência
├── 05_backlog.md tarefas em ordem, com critério de aceite
└── benchmarks/ pesquisa de origem, com URL em cada afirmação
| Se você é | Leia |
|---|---|
| Desenvolvedor | CLAUDE.md, depois docs/03, docs/04 e docs/05 |
| Designer | docs/02. É autocontido, dá para colar no Claude Design |
| Sócio ou decisor | docs/01, seções 1 (Ficha de Entrega), 2 (benchmark) e 3 (alerta comercial) |
| Decisão | Valor |
|---|---|
| Corte do V1 | MVP fechado, agenda própria, sem integração com sistema de gestão |
| Stack | Next.js 15 + TypeScript + Tailwind + shadcn/ui + Supabase |
| Região do banco | sa-east-1 (São Paulo), para remover a discussão de transferência internacional |
| Preço | R$ 597 (Essencial) e R$ 897 (Completo), por clínica, usuários ilimitados |
| Visual | Claro por padrão, escuro obrigatório (decisão de 19/08/2026, revisando o brief) |
| Arquitetura | Nasce clínicas, com white-label e nomenclatura parametrizados desde o dia 1 |
| Ordem de integração (V2) | Feegow, depois Ninsaúde e Shosp, iClinic por último e só com acordo com a Afya |
| Prazo estimado | 21 semanas do design ao piloto medido, com 1 dev em tempo integral |
A conta não fecha em 15 clientes. No cenário otimista (15 de 15 adotando a R$ 897) são R$ 13.455 de MRR contra um time mínimo de R$ 15.000. São necessárias entre 17 e 26 clínicas só para empatar, sem contar custo variável. A memória de cálculo está na seção 3 da spec.
Nenhuma delas bloqueia o código. Todas viram configuração, nunca valor fixo.
Os documentos usam três marcações:
[FONTE] sustentado por benchmark com URL em docs/benchmarks/[PREMISSA] hipótese de trabalho sem fonte externa, a validar[PENDENTE] dado necessário ainda não levantadoTodo número tem memória de cálculo aberta. O que não tem fonte está marcado, não escondido.