아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
최근 완료된 8시간 회차 사이 GitHub 스타 증가량 순
의사가 만든 58개 오픈소스 스킬로 의료 연구 전 과정을 지원
인간 건강의 표준 레지스트리, 약 2천 개 임상·생활 지표를 하나의 언어로 정리
당뇨 관리용 차세대 플랫폼
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Sistema de citas odontológicas para la clínica de la Dra. Belkis Suisse. Proyecto de Ingeniería de Software II. El código de verificación está también en /verificacion.txt y en la etiqueta de la landing y del login. Para entrar al portal: usuario jaleman en la pestaña Doctora del login. La contraseña va aparte — no está en el repositorio. Es una cuenta de evaluación con el mismo alcance que la de la doctora; no hay roles, así que sólo tiene sentido mientras la base lleve datos de prueba.README 전문 보기 ↗
Sistema de citas odontológicas para la clínica de la Dra. Belkis Suisse. Proyecto de Ingeniería de Software II.
Código de verificación: LEARN-CAP-C72DC553
| URL | |
|---|---|
| 🌐 Sitio | https://www.angiehernndz.lat |
| 🔑 Login | https://www.angiehernndz.lat/login |
| 🔒 Portal privado | https://www.angiehernndz.lat/admin |
| ❤️ Healthcheck | https://www.angiehernndz.lat/api/health |
| 🎞️ Presentación | presentacion.html |
El código de verificación está también en
/verificacion.txt y en la
etiqueta <meta name="verificacion"> de la landing y del login.
Para entrar al portal: usuario jaleman en la pestaña Doctora del login.
La contraseña va aparte — no está en el repositorio. Es una cuenta de
evaluación con el mismo alcance que la de la doctora; no hay roles, así que
sólo tiene sentido mientras la base lleve datos de prueba.
Una aplicación web para dos perfiles:
Sitio estático sin framework ni paso de compilación: HTML, CSS y módulos ES
nativos, con cuatro funciones serverless en Vercel y Supabase como base de
datos. El cliente no tiene dependencias; las únicas del package.json son de
desarrollo.
| Capa | Qué hay |
|---|---|
| Cliente | index.html, landing.html, presentacion.html, assets/js/ |
| Serverless | api/ — sesión, portal privado, proxy de datos y healthcheck |
| Base | PostgreSQL en Supabase, vía PostgREST |
La arquitectura completa, con diagramas C4, está en
docs/arquitectura.md. Las decisiones estructurales,
en docs/adr/: ADR-001 — evolución
y ADR-002 — experiencia.
El portal privado no se sirve sin sesión. El panel de la doctora vive en
api/_portal.js — los archivos con guion bajo en api/ no se publican como
ruta — y sólo lo entrega api/admin.js tras validar una cookie HttpOnly contra
Supabase. Sin sesión responde 302 sin una línea de marcado privado.
El token nunca baja al navegador. El panel pide sus datos a
api/db/[tabla].js, que reenvía a PostgREST firmando del lado del servidor. La
app arma HTML a partir de nombres y diagnósticos, así que exponer el token sería
regalárselo a un XSS.
El paciente no toca ninguna tabla. Sus cinco operaciones — alta, horarios
ocupados, crear solicitud, consultar estado y cancelar — pasan por funciones
security definer que exponen sólo lo de su pantalla.
Todo es idempotente. Repetir cualquier operación deja el mismo estado: un
reintento tras un timeout, un doble clic o una segunda pestaña no duplican nada.
crear_solicitud resuelve la comprobación y la inserción en una sola sentencia,
así que la garantía vive en la base y no en una convención del cliente.
Tres niveles de caché. Lecturas en memoria con vencimiento, service worker para funcionar sin conexión, y estáticos sellados con el hash de su contenido. Cinco lecturas van sin caché a propósito: de ellas depende si se escribe o no.
Los módulos ES no cargan por file://. Hay que servirlo por HTTP desde la raíz:
npx http-server . -p 8080 -c-1
Y entrar por http://localhost:8080/landing.html. El service worker sólo se
registra sobre HTTPS o localhost.
Runner nativo de Node, sin dependencias. Corren en CI en cada push y cada pull
request a main (.github/workflows/main.yml).
npm test # unidad + integración
npm run test:unidad
npm run test:integracion
npm run cobertura # reporte a coverage/, falla si baja del mínimo
Qué cubre cada archivo y cómo está armada la base falsa:
test/README.md. El caso central es doble-reserva: dos
pacientes no pueden quedarse con el mismo horario.
Ninguno necesita dependencias: todo sale de la biblioteca estándar de Node.
| Comando | Qué hace |
|---|---|
npm run versionar | Sella los estáticos con el hash de su contenido. Correlo antes de publicar. |
npm run imagenes | Regenera iconos PNG e imagen social |
npm run verificar:sitio | Audita el sitio en vivo contra el checklist del entregable |
npm run verificar:rls | Comprueba, con la anon key, que la base no esté expuesta |
npm run verificar:esquema | Valida docs/db-export.json contra lo que exige el entregable |
Son idempotentes: si nada cambió, no tocan nada.
Los scripts SQL están en migracion/, numerados y con sus
dependencias documentadas en migracion/README.md. El
esquema real, exportado con scripts/exportar-esquema.sql, queda en
docs/db-export.json.
Vercel, conectado al repositorio: cada push a main redespliega. La
configuración de headers y rutas está en vercel.json.
Para saber qué versión está publicada, mirá el campo version del healthcheck:
coincide con el hash que escribe versionar.mjs.