argos-harness 0.1.0

package/assets/skills/judgment-day/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: judgment-day
+description: Run blind dual review, fix confirmed issues, then re-judge. Trigger: judgment day, dual review, adversarial review, juzgar.
+---
+
+## Activation Contract
+
+Load this skill only when the user explicitly asks for Judgment Day, dual/adversarial review, or equivalent Spanish trigger (`juzgar`, `que lo juzguen`). Review a specific target: files, feature, PR, or architecture slice.
+
+## Hard Rules
+
+- Resolve project skills before launching agents: if the harness exposes a skill index, use it to resolve exact `SKILL.md` paths; otherwise, search the installed skills directory for the skills that match the target files/task by name. Inject the same `Skills to load before work` block into both judge prompts and fix prompts.
+- Launch **two blind judges in parallel** with identical target and criteria; never review the code yourself.
+- Wait for both judges before synthesis; never accept a partial verdict.
+- Classify warnings as `WARNING (real)` only if normal intended use can trigger them; otherwise downgrade to INFO as `WARNING (theoretical)`.
+- Ask before fixing Round 1 confirmed issues.
+- After any fix agent runs, immediately re-launch both judges in parallel before commit/push/done/session summary.
+- Terminal states are only `JUDGMENT: APPROVED` or `JUDGMENT: ESCALATED`.
+- After 2 fix iterations with remaining issues, ask the user whether to continue.
+
+## Decision Gates
+
+| Condition | Action |
+|---|---|
+| Target unclear | Ask for scope; do not launch judges. |
+| No skill index and nothing found by name search | Warn, proceed with generic criteria, and record `Skill Resolution: none`. |
+| Both judges find same CRITICAL/real WARNING | Confirmed; ask/fix according to round rules. |
+| One judge finds issue | Suspect; report and triage, do not auto-fix. |
+| Judges contradict | Escalate for manual decision. |
+| Round 2+ has only theoretical warnings/suggestions | Report as INFO; do not re-judge. |
+
+## Execution Steps
+
+1. Confirm target and optional custom criteria.
+2. Resolve exact skill paths via the harness's skill index if one is available, or by searching the skills directory for matching `SKILL.md` files; warn if none are found.
+3. Start Judge A and Judge B concurrently via delegation.
+4. Synthesize findings into confirmed, suspect, contradiction, and INFO buckets.
+5. Ask before Round 1 fixes; delegate a separate fix agent for confirmed approved fixes only.
+6. Re-judge in parallel after fixes; repeat until approved, escalated, or user asks to stop.
+7. Before any terminal action, verify every active Judgment Day has a terminal state.
+
+## Output Contract
+
+Return `## Judgment Day — {target}` with round number, verdict table, confirmed/suspect/contradiction counts, fixes applied, re-judgment result, `Skill Resolution`, and final `JUDGMENT: APPROVED ✅` or `JUDGMENT: ESCALATED ⚠️`.
+
+## References
+
+- [references/prompts-and-formats.md](references/prompts-and-formats.md) — judge/fix prompts, warning rubric, verdict tables, and language snippets.
+
+---
+
+_Adapted from a skill originally authored by gentleman-programming._

package/assets/skills/judgment-day/references/prompts-and-formats.md

@@ -0,0 +1,98 @@
+# Judgment Day Prompts and Formats
+
+## Judge Prompt
+
+```markdown
+You are an adversarial code reviewer. Your ONLY job is to find problems.
+
+## Target
+{files, feature, architecture, component}
+
+## Skills to load before work
+{matching SKILL.md paths, if available}
+
+## Review Criteria
+- Correctness: logical errors and behavior mismatches
+- Edge cases: missing states, inputs, or platform constraints
+- Error handling: propagation, logging, recovery
+- Performance: N+1, wasteful loops, excessive allocations
+- Security: injection, secrets, auth boundaries
+- Naming/conventions: project standards and local patterns
+{custom criteria, if provided}
+
+## Return Format
+Findings only. No praise.
+
+Each finding:
+- Severity: CRITICAL | WARNING (real) | WARNING (theoretical) | SUGGESTION
+- File: path/to/file.ext (line N if applicable)
+- Description: what is wrong and why it matters
+- Suggested fix: one-line intent
+
+WARNING rule: normal intended use can trigger it → `WARNING (real)`; contrived/malicious/impossible path → `WARNING (theoretical)`.
+
+If clean: `VERDICT: CLEAN — No issues found.`
+
+Always end with: `Skill Resolution: {paths-injected|fallback-index|fallback-path|none} — {details}`.
+```
+
+## Fix Agent Prompt
+
+```markdown
+You are a surgical fix agent. Apply ONLY the confirmed issues listed below.
+
+## Confirmed Issues to Fix
+{confirmed findings table}
+
+## Skills to load before work
+{matching SKILL.md paths, if available}
+
+## Instructions
+- Fix only confirmed issues.
+- Do not refactor beyond the required fix.
+- Do not change unflagged code.
+- If fixing a repeated pattern in touched files, fix all occurrences of that same pattern.
+- Return changed file, line, and fix summary.
+
+End with: `Skill Resolution: {paths-injected|fallback-index|fallback-path|none} — {details}`.
+```
+
+## Verdict Table
+
+```markdown
+| Finding | Judge A | Judge B | Severity | Status |
+|---------|---------|---------|----------|--------|
+| Missing null check in auth.go:42 | ✅ | ✅ | CRITICAL | Confirmed |
+| Windows volume root edge case | ❌ | ✅ | WARNING (theoretical) | INFO |
+| Naming mismatch | ✅ | ❌ | SUGGESTION | Suspect |
+```
+
+Approved criteria after Round 1: zero confirmed CRITICALs and zero confirmed real WARNINGs. Theoretical warnings and suggestions may remain.
+
+## Delegation Patterns
+
+When JD agents are configured as named sub-agents (Claude Code's `jd-judge-a`, `jd-judge-b`, and `jd-fix-agent`, or an equivalent multi-mode overlay in another harness), use named delegation:
+
+```
+Judge A:   delegate(agent="jd-judge-a", prompt="...")
+Judge B:   delegate(agent="jd-judge-b", prompt="...")
+Fix Agent: delegate(agent="jd-fix-agent", prompt="...")
+```
+
+Each named agent uses its configured model from the Model Assignments table.
+
+When named JD agents are NOT available (Cursor, Windsurf, Gemini, Codex, etc.), use the adapter's generic delegate syntax. These adapters do not support the `agent` parameter — all calls use the same delegate entry point and the model is controlled externally:
+
+```
+// Generic delegate — no named agent support; adapter-native syntax
+Judge A:   delegate(prompt="...")
+Judge B:   delegate(prompt="...")
+Fix Agent: delegate(prompt="...")
+```
+
+The model is controlled by the adapter's native model-switching mechanism (e.g., model sentinels in agent .md files). Pass the model alias from the Model Assignments table if the adapter supports per-call model parameters.
+
+## Language Snippets
+
+- Spanish: “Juicio iniciado”, “Los jueces trabajan en paralelo”, “Los jueces coinciden”, “Juicio terminado — Aprobado”, “Escalado — necesita revisión humana”.
+- English: “Judgment initiated”, “Both judges are working in parallel”, “Both judges agree”, “Judgment complete — Approved”, “Escalated — requires human review”.

package/assets/skills/lightsail-deploy/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: lightsail-deploy
+description: Operate and debug Bonum service deploys to AWS Lightsail (notifications, reports360). Trigger: deploy, despliegue, Lightsail, dev environment, deployment failed, container canceled, ECR pull.
+---
+
+## Activation Contract
+
+Use when deploying any Bonum service to Lightsail, creating a new Lightsail service, debugging a failed/canceled deployment, or verifying a deploy end-to-end.
+
+## Hard Rules
+
+- Deploys go through GitHub Actions only: push to `develop` (development) or `main` (production). No manual Lightsail deploys.
+- Every NEW Lightsail service MUST have `ecrImagePullerRole` activated and its `principalArn` MERGED into the ECR repo policy — never overwrite existing statements. Without it, containers never start and logs stay empty.
+- Never commit `.env`; local copies hold real credentials.
+- Health checks accept success codes 200-499. A 404 on `/` is healthy.
+- Docker builds use buildx with `cache-from/to: type=gha`.
+
+## Decision Gates
+
+| Service | ECR repo | Secrets model |
+|---|---|---|
+| notifications--server | `notifications` | GitHub environments `development`/`production`, same secret names, env-scoped values |
+| reports-server-bonum | `reports360` | Repo-level secrets (`MONGODB_URI`, AWS keys); env split happens in `config.py` via `ENVIRONMENT` |
+
+| Symptom | Cause / Action |
+|---|---|
+| `Started 1 new node` ×3 then `Canceled`, empty logs | Image pull failure → check `ecrImagePullerRole` + ECR policy (runbook) |
+| Logs empty right after deploy | Lightsail log lag is minutes — wait, don't rediagnose |
+| App logs errors on boot | Check env vars/secrets for that service (runbook lists them) |
+| Need AWS API without local CLI | Use `curl --aws-sigv4` recipes in runbook |
+
+## Execution Steps
+
+1. Merge/push to the target branch; the workflow tests (where applicable), builds, pushes to ECR, and calls `create-container-service-deployment`.
+2. Poll deployment state until `ACTIVE` (~5 min floor; Lightsail blue/green is not compressible).
+3. Verify end-to-end per service (runbook: test email payload for notifications, report endpoint for reports360).
+
+## Output Contract
+
+Report deployment state (`ACTIVE`/`FAILED`), service URL, and log evidence of the service's external connections (Mongo, RabbitMQ, evaluations API).
+
+## References
+
+- `references/runbook.md` — per-service topology, sigv4 curl recipes, new-service checklist, secret lists, known gotchas.

package/assets/skills/lightsail-deploy/references/runbook.md

@@ -0,0 +1,102 @@
+# Lightsail Deploy Runbook — Bonum services
+
+Learned 2026-07-22/23 while bringing up the dev environments.
+
+## Shared topology
+
+- AWS account `762614731979`, region `us-east-1` for ECR and Lightsail.
+- ECR registry: `762614731979.dkr.ecr.us-east-1.amazonaws.com`.
+- MongoDB Atlas: single shared cluster; env separation is per database, not per cluster.
+- RabbitMQ: single shared broker `amqp://3.144.196.4` (notifications only).
+
+## Per-service topology
+
+### notifications--server (Node)
+
+- ECR repo `notifications`; tags `notifications-dev-<sha>` (dev) / `notifications-<sha>` (prod).
+- Dev: Lightsail `notifications-server-dev` (nano/512MB), URL `https://notifications-server-dev.tclik5ai2vodi.us-east-1.cs.amazonlightsail.com/`. Prod: `container-service-1` (small/1GB). Port 3002.
+- Workflows: `develop.yml` + `main.yml` (near-clones; differ in branch, GitHub environment, service name).
+- Queues `correos` (prod) / `correos_dev` (dev, hardcoded `EMAIL_QUEUE` in develop.yml). Queue is `durable: false`.
+- Secrets in GitHub environments `development`/`production`: `AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, ONE_SIGNAL_REST_API_KEY, ONE_SIGNAL_API_URL, ONE_SIGNAL_APP_ID, EMAIL_PASSWORD, EMAIL_USER, EMAIL_FROM, SMTP_USER, SMTP_PASS, MONGO_USER, MONGO_PASSWORD, MONGO_DATABASE, MONGO_CLUSTER, NEXUS_API_URL` (+ `PORT`). Bulk upload: `gh secret set -f .env.dev --env development --repo bonumtech1/notifications--server`.
+- `RABBITMQ_URL` intentionally absent in dev → falls back to shared prod broker with the `correos_dev` queue.
+
+### reports-server-bonum (Python/Flask)
+
+- ECR repo `reports360`; tags `reports360v1` (prod) / `reports360-dev` (dev) — fixed tags, not per-sha.
+- Prod: Lightsail `container-reports360`. Dev: `container-reports360-dev` (nano). Port 8000.
+- Single workflow `deploy.yml` triggers on `main` AND `develop`; branch derives `DEPLOY_ENV`, `IMAGE_TAG`, `SERVICE_NAME` at job level.
+- Secrets at REPO level (no GitHub environments by design): `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `MONGODB_URI`. Same Atlas URI both envs; `config.py` picks DB by `ENVIRONMENT`: production → `bonum_production` with fallback `bonum`; development → `bonum` only, plus dev evaluations URL.
+- Tests (`test_config.py`, `test_report_helpers.py`) gate the build; missing `MONGODB_URI` = intentional crashloop (fail-fast).
+- Health check path `/`, success codes 200-499.
+
+## New Lightsail service checklist
+
+1. Create the container service (console or API), region us-east-1.
+2. Activate ECR pull access:
+   ```
+   UpdateContainerService {"serviceName":"<svc>","privateRegistryAccess":{"ecrImagePullerRole":{"isActive":true}}}
+   ```
+   Service goes `UPDATING`/`PROVISIONING_SERVICE` for a few minutes; `principalArn` is empty until it finishes. Poll `GetContainerServices`.
+3. MERGE the new `principalArn` into the ECR repo policy as a new statement (`Sid: AllowLightsailPull-<svc>`, actions `ecr:BatchGetImage`, `ecr:GetDownloadUrlForLayer`). Fetch the existing policy first and append — never clobber (other services' statements live there).
+4. Ensure the secrets exist where that service expects them (GitHub environment for notifications, repo level for reports360).
+5. Push to the trigger branch or `gh run rerun <run-id>`.
+
+## AWS API without local CLI (curl sigv4)
+
+Keys come from local `.env` (`AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY`).
+
+```bash
+# Lightsail (JSON-RPC): GetContainerServices, GetContainerLog,
+# GetContainerServiceDeployments, UpdateContainerService
+curl -s "https://lightsail.us-east-1.amazonaws.com/" \
+  -H "X-Amz-Target: Lightsail_20161128.<Operation>" \
+  -H "Content-Type: application/x-amz-json-1.1" \
+  -d '{"serviceName":"<service-name>"}' \
+  --aws-sigv4 "aws:amz:us-east-1:lightsail" --user "$KEY:$SECRET"
+
+# ECR: GetRepositoryPolicy / SetRepositoryPolicy
+curl -s "https://api.ecr.us-east-1.amazonaws.com/" \
+  -H "X-Amz-Target: AmazonEC2ContainerRegistry_V20150921.<Operation>" \
+  -H "Content-Type: application/x-amz-json-1.1" \
+  -d '{"repositoryName":"<ecr-repo>"}' \
+  --aws-sigv4 "aws:amz:us-east-1:ecr" --user "$KEY:$SECRET"
+```
+
+`GetContainerLog` needs `serviceName` AND `containerName` (for notifications both equal the service name; for reports360 the container is `reports360-container`).
+
+## Failure signatures
+
+- **`Started 1 new node` ×3 → `Canceled`, zero app log lines**: the container never ran — image pull failure. Check `ecrImagePullerRole.isActive` and the ECR policy statement.
+- **Container logs lag several minutes** behind reality; a "Get logs" step right after deploy always prints `logEvents: []` (misleading, not broken — removed from workflows).
+- **`nano` power (dev) = 512MB**: if the app OOMs or restarts under load, bump to `small` like prod.
+
+## End-to-end verification
+
+### notifications: test email
+
+Publish to the dev queue with the project's own `amqplib` (payload hits `treatTypes` default case → straight to `sendEmail`; `checking_in` only needs `coacheeName`):
+
+```js
+const payload = {
+  emails: ["<recipient>"],
+  subject: "Dev environment test - correos_dev",
+  mailTemplate: "checking_in", // BARE template name — sendEmail appends _<language> itself (checking_in_es would resolve to checking_in_es/checking_in_es_es.hbs and ENOENT)
+  clientTheme: "bonum",
+  language: "es",
+  type: null,
+  context: { coacheeName: "Ricardo" },
+};
+// ch.assertQueue("correos_dev", { durable: false }); ch.sendToQueue(...)
+```
+
+Then confirm `📨 MENSAJE RECIBIDO!` / `email to send` in container logs (mind the lag).
+
+### reports360: boot + report
+
+Container must NOT be in crashloop (crashloop right after deploy = missing `MONGODB_URI`). Hit `/` (404 is healthy) and generate a report against a known dev evaluation to confirm Mongo + evaluations API connectivity.
+
+## Gotchas
+
+- Repos live under a personal account (`bonumtech1`): collaborators cannot get admin; only the owner manages environments/secrets. Environments on private personal repos require GitHub Pro.
+- Lightsail has no Secrets Manager integration; container env vars are visible in plaintext to anyone with read access to the service. Keep IAM scoped.
+- Time floor: ~5 min of Lightsail blue/green (`ACTIVATING`) that no workflow change can reduce.

package/assets/skills/loop-back-debug/SKILL.md

@@ -0,0 +1,102 @@
+---
+name: loop-back-debug
+description: Protocolo para cuando un fix no resuelve el síntoma la primera vez — fuerza re-leer el síntoma original, validar la hipótesis contra el diff aplicado, y generar hipótesis alternativas antes de aplicar otro patch. Trigger: un fix aplicado no elimina el bug en el repro, o se acumulan varios intentos fallidos sobre el mismo síntoma.
+---
+
+# Loop-Back Debug
+
+## El anti-pattern que este skill ataca
+
+Patrón recurrente cuando un bug es persistente:
+
+1. Intento de fix #1 → "debería andar" → no anda.
+2. Intento de fix #2 → "ahora sí" → no anda.
+3. Intento de fix #3 → cambio random → no anda.
+4. Eventualmente el código está peor que al inicio y el bug sigue.
+
+El error de raíz es **escalar el cambio sin re-validar la hipótesis**. Cada intento asume que el anterior estaba "casi bien", cuando en realidad el modelo mental del bug estaba mal desde el #1.
+
+## La regla
+
+```
+SI UN FIX NO ARREGLÓ EL SÍNTOMA EN EL PRIMER REPRO POST-FIX,
+PARAS DE PATCHEAR Y RE-VALIDAS LA HIPÓTESIS.
+```
+
+No más patches encima del patch anterior. Vuelves al síntoma original y al diff actual, comparas contra la hipótesis. Si la hipótesis era correcta y el síntoma persiste, el fix no es completo. Si la hipótesis era incorrecta, ningún patch sobre esta línea va a funcionar — cambia la hipótesis.
+
+## Función de gate (post-fix)
+
+DESPUÉS de aplicar un fix y ANTES de afirmar "arreglado":
+
+1. **REPRO**: corre el repro exacto que producía el síntoma original. En este turno. No "asumiendo que".
+2. **OBSERVE**: ¿el síntoma sigue / cambió / desapareció?
+3. **CLASSIFY**:
+   - **Desapareció** → aplica `verify-before-done` para confirmar y declarar fix completo.
+   - **Persiste exactamente igual** → hipótesis estaba mal. NO patchees encima. Vuelve a § Reset hipótesis.
+   - **Cambió de forma** → el fix tocó algo real pero no era la causa raíz. Vuelve a § Reset hipótesis con la nueva info.
+
+## Reset hipótesis (cuando el fix no funcionó)
+
+NO aplicar otro fix hasta completar estos pasos:
+
+1. **Lee de vuelta el síntoma original**, literal del ticket / bug report / repro inicial. No el síntoma de tu cabeza, el escrito.
+2. **Lista el diff aplicado** (`git diff HEAD~1`) y descríbelo en una frase: "Cambié X en archivo:línea de Y a Z porque hipótesis era W".
+3. **Valida lógicamente**: si la hipótesis W fuera cierta, ¿el cambio Y→Z debería haber arreglado el síntoma?
+   - Si la respuesta es "sí debería", pero el síntoma persiste → tu modelo del flujo está incompleto. Hay un step intermedio que no estás viendo.
+   - Si la respuesta es "no necesariamente", la hipótesis era débil desde el inicio.
+4. **Genera 2–3 hipótesis alternativas** antes de tocar código:
+   - ¿Hay caching? (browser, build, CDN, redis).
+   - ¿El código que cambiaste es el que se ejecuta? (path resolution, dynamic imports, env-gated branches).
+   - ¿El cambio fue al server o al cliente cuando el bug está del otro lado?
+   - ¿Hay un middleware / interceptor entre lo que cambiaste y donde se observa el síntoma?
+   - ¿El estado en memoria / DB ya estaba en un estado inválido y tu fix solo cubre el path "nuevo"?
+   - Si el repo convive con código legacy y código nuevo (rutas legacy declaradas en `project.legacyPaths` de su `argos.config.json`), ¿el fix tocó el path que realmente se ejecuta, o el otro?
+5. **Elige UNA hipótesis nueva** con razonamiento basado en evidencia. Documéntala antes de tocar código.
+6. **Aplica el siguiente intento** sabiendo qué estás probando.
+
+## Cuándo escalar / pedir ayuda al usuario
+
+Si llevas **2 intentos fallidos** sobre el mismo bug, paras y reportas al usuario:
+
+- Síntoma original.
+- Hipótesis #1, fix aplicado, resultado del repro.
+- Hipótesis #2, fix aplicado, resultado del repro.
+- Hipótesis #3 que piensas probar, con evidencia que la sustenta.
+- Pregunta concreta: "¿conoces más contexto que apoye / refute esta hipótesis?"
+
+No es debilidad — es eficiencia. 3 intentos a ciegas valen menos que 1 conversación con quien tiene contexto.
+
+## Señales de alerta (PARA)
+
+- Estás por hacer un segundo cambio sobre la misma línea sin haber re-corrido el repro.
+- Estás por escribir "ahora sí debería andar" sin evidencia fresca.
+- Estás revertiendo y re-aplicando variaciones del mismo cambio.
+- Estás agregando logs / try-catch / fallbacks para "cubrir" en vez de entender.
+- El diff acumula >3 commits sobre el mismo archivo intentando arreglar la misma cosa.
+
+## Anti-patrones
+
+- ❌ "Voy a probar esto otro fix" sin haber corrido el repro del fix anterior.
+- ❌ Patches defensivos: try-catch alrededor del código sospechoso para "que no rompa". Eso oculta el bug, no lo arregla.
+- ❌ "Es flaky" como excusa sin evidencia de flakiness real.
+- ❌ Cambiar lib / framework / approach porque "tal vez con X andaría" — eso es ducha caliente, no debugging.
+- ❌ Pedirle al usuario "pruébalo de nuevo" sin haber cambiado nada relevante.
+
+## Conexión con el resto del harness
+
+- `implementer`: invoca este skill cuando el primer fix no resuelve el síntoma. NO devuelve `done` hasta haber pasado por Reset hipótesis si el repro inicial falla.
+- `verify-before-done`: este skill se aplica ANTES de verify-before-done — primero validas que el fix realmente arregló el síntoma (esto), luego validas que el resto del quality gate sigue verde (verify-before-done).
+- `ticket-audit`: cuando un bug entra al agente ticket-audit, la "Hipótesis de causa raíz" es el primer candidate del loop. Si el fix de esa hipótesis no funciona, ticket-audit puede ser reinvocado con la info nueva.
+
+## Cierre
+
+Al aplicar este skill, el output al usuario incluye:
+
+1. Hipótesis que se probó.
+2. Cambio aplicado (archivo:línea + descripción).
+3. Resultado del repro post-fix (en este turno).
+4. Si funcionó → aplicar `verify-before-done` para cierre.
+5. Si no funcionó → próxima hipótesis a probar O escalación al usuario (según conteo de intentos).
+
+Este skill vive una sola vez en el motor global y aplica a cualquier repo. Los patrones de bug recurrentes de un proyecto concreto (caches que ese repo suele olvidar invalidar, race conditions conocidas en un módulo, comandos de repro estandarizados) no se agregan a este archivo: viven en la ficha del repo o en `argos.config.json` (por ejemplo `project.legacyPaths` para migraciones a medias), y se leen en runtime al depurar ese repo específico.

package/assets/skills/mantine-form/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: mantine-form
+description: Patrones de @mantine/form — useForm, getInputProps, validación con zodResolver, campos anidados y listas. Trigger: al crear o tocar formularios con Mantine.
+---
+
+# Mantine Form — convenciones
+
+## Cuándo usar este skill
+
+Al crear o tocar un formulario con `@mantine/form`: cablear inputs de Mantine, validar, manejar submit, o campos anidados/listas. `useForm` es la fuente de verdad del form — no espejees sus valores en `useState`, y valida con un schema Zod (vía `mantine-form-zod-resolver`), no con funciones sueltas por campo.
+
+## El patrón
+
+`useForm` + `getInputProps` (esparce value/onChange/error de un jalón) + `zodResolver` para el schema:
+
+```tsx
+const schema = z.object({
+  email: z.string().email(),
+  role: z.enum(['coach', 'coachee']),
+});
+
+const form = useForm({
+  mode: 'uncontrolled',                 // menos re-renders; el default recomendado
+  initialValues: { email: '', role: 'coachee' },
+  validate: zodResolver(schema),        // desde 'mantine-form-zod-resolver'
+});
+
+<form onSubmit={form.onSubmit((values) => save(values))}>
+  <TextInput {...form.getInputProps('email')} />
+  <Select data={['coach', 'coachee']} {...form.getInputProps('role')} />
+  <Button type="submit">Guardar</Button>
+</form>
+```
+
+## Gotchas que muerden
+
+- **`getInputProps('campo')` cablea todo; no lo desarmes.** Ya trae `value`/`onChange`/`error`/`onBlur`. Pasar `value`/`onChange` a mano encima rompe el binding — deja que el spread mande.
+- **`mode: 'uncontrolled'` cambia cómo lees valores.** En uncontrolled, `form.values` no re-renderiza al teclear; para reflejar un campo en la UI usa `form.watch('campo')` o `form.getValues()`. En `controlled` sí re-renderiza cada tecla (más caro en forms grandes).
+- **Validación con `zodResolver`, no funciones por campo.** `validate: { email: (v) => … }` disemina reglas y tipos. Un schema Zod + `zodResolver` da una fuente única y el tipo por `z.infer`. Requiere el paquete `mantine-form-zod-resolver`.
+- **Campos anidados/listas con notación de path.** `getInputProps('address.city')`, y listas con `form.insertListItem('items', {...})` / `form.removeListItem('items', i)` + `getInputProps('items.0.name')`. No manejes el array en `useState` aparte.
+- **`initialValues` define el shape; llénalo completo.** Un campo ausente arranca `undefined` → warning uncontrolled→controlled. Para edición async usa `form.setValues(data)` / `form.initialize(data)` en un efecto, no valores a mano por render.
+- **Submit con `form.onSubmit(handler)`.** Corre la validación y solo llama tu handler si pasa; además expone el segundo callback `(errors) => …` para enfocar el primer inválido. No valides "a mano" antes de enviar.
+
+## Reglas duras
+
+1. `useForm` es la única fuente del estado del form; nada de `useState` espejo.
+2. Inputs cableados con `getInputProps`; no dupliques `value`/`onChange`.
+3. Validación con schema Zod vía `zodResolver`; tipo por `z.infer`, sin reglas por campo.
+4. `initialValues` completo; edición async con `setValues`/`initialize`.
+5. Submit vía `form.onSubmit`; listas/anidados con la API de path, no arrays sueltos.
+
+## Antes de declarar listo
+
+- Todos los inputs usan `getInputProps`; sin estado espejo ni handlers duplicados.
+- Validación centralizada en un schema Zod con `zodResolver`; tipos por `z.infer`.
+- `initialValues` seteado; sin warnings uncontrolled→controlled. Submit con `form.onSubmit`.
+- El quality gate del repo (`qualityGate.fast` en `argos.config.json`) en verde.

package/assets/skills/mongoose/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: mongoose
+description: Patrones de Mongoose en un servicio TS — queries seguras, populate, paginate, soft delete, ObjectId, evitar N+1. Trigger: al tocar domain/models u ops de Mongoose en controllers.
+---
+
+# Mongoose — convenciones del servicio
+
+## Cuándo usar este skill
+
+Cuando la tarea toca `domain/models` o ejecuta operaciones de Mongoose en los controllers. Sin repository wrappers: los controllers tocan los Models directo, así que null-guards, casts de ObjectId y `.lean()` viven en cada controller method.
+
+En **NestJS** (`@nestjs/mongoose`) el Model se inyecta: `@InjectModel(Resource.name) private model: Model<ResourceDocument>`; el resto de patrones aplican igual.
+
+## Patrón canónico
+
+```ts
+const doc = await Resource.findById(id);
+if (!doc) throw new NotFoundError(`Resource ${id} not found`);
+
+const docs = await Resource.find(filter).lean<IResource[]>();  // read-only
+
+const updated = await Resource.findByIdAndUpdate(
+  id, { $set: dto }, { returnDocument: 'after', runValidators: true }
+);
+```
+
+`returnDocument: 'after'` (reemplaza el deprecado `new: true`) devuelve el doc actualizado; `runValidators: true` valida el update parcial. Ojo: `findByIdAndUpdate` **no** dispara hooks `pre('save')` ni valida el doc completo — si hay lógica en middleware `save`, usa `doc.save()`.
+
+## ObjectId — la trampa más común
+
+Un `id` de `req.params`/`req.body` es **string**. `findById` lo castea solo, pero aggregations y queries complejas requieren `new Types.ObjectId(id)` (el `new` es obligatorio en Mongoose 6+). Valida el formato antes (`/^[a-f\d]{24}$/i`) o un string mal-formado lanza `CastError`. Compara ObjectId con `.equals()`, nunca `==`.
+
+## Gotchas que muerden
+
+- **Query injection**: `Model.find(req.query)` crudo deja pasar operadores (`{ $ne: null }`). Arma el filtro campo por campo o `.setOptions({ sanitizeFilter: true })`. Y `strictQuery` es `false` por default (Mongoose 7+): un campo con typo se ignora → filtro vacío que devuelve **toda** la colección.
+- **Atomicidad multi-doc**: escrituras relacionadas en `connection.transaction(async (session) => {...})`, pasando `{ session }` a cada op. `bulkWrite` no es transacción.
+- **Índices**: filtros y `.sort()` sobre campos sin índice = COLLSCAN. Declara `schema.index(...)`, verifica con `.explain()`.
+- **populate** batchea con `$in` (1 query por path, no N); no filtra/ordena por el child — ahí `$lookup`. `.lean()` pierde `.save()`/virtuals.
+- **Soft delete**: con `mongoose-delete`, `find` ya excluye `deleted: true`; borra con `doc.delete()` (no `findByIdAndDelete`), restaura con `doc.restore()`.
+
+## Reglas duras
+
+1. **Ops de Mongoose nunca en la ruta** — siempre dentro de un controller method.
+2. **Null-guard tras `findById`/`findOne`** — `if (!doc) throw new NotFoundError(...)`.
+3. **`.lean()` cuando no necesitas mutar**; comparar ObjectId con `.equals()`, nunca `==`.
+4. **Nunca `Model.find(req.query)` crudo** — filtro campo por campo o `sanitizeFilter`.
+5. **Respeta el soft delete del repo**; escrituras relacionadas en `connection.transaction`.
+
+## Tabla rápida
+
+| Necesito | Cómo |
+|---|---|
+| Buscar por id | `findById(id)` + null-guard → `NotFoundError` |
+| Cast string → ObjectId | `new Types.ObjectId(id)` |
+| Query read-only | `.find(filter).lean()` |
+| Paginar | `.paginate(...)` o `skip().limit()` + `countDocuments` |
+| Borrar con soft delete | `doc.delete()` (no `findByIdAndDelete`) |
+| Update devolviendo el nuevo | `findByIdAndUpdate(id, { $set }, { returnDocument: 'after', runValidators: true })` |
+| Escrituras relacionadas | `connection.transaction(async (session) => …)` |
+
+## Antes de declarar listo
+
+- Cada `findById`/`findOne` tiene null-guard → `NotFoundError`; read-only con `.lean()`.
+- Ningún filtro arma con `req.query`/`req.body` crudo; ObjectId comparado con `.equals()`.
+- Borrados respetan soft delete; escrituras relacionadas van en transacción.
+- El quality gate del repo (`qualityGate.fast` en `argos.config.json`) en verde.

package/assets/skills/nextjs-15/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: nextjs-15
+description: Next.js 15 App Router patterns. Trigger: When working with Next.js - routing, Server Actions, data fetching.
+---
+
+## App Router File Conventions
+
+```
+app/
+├── layout.tsx          # Root layout (required)
+├── page.tsx            # Home page (/)
+├── loading.tsx         # Loading UI (Suspense)
+├── error.tsx           # Error boundary
+├── not-found.tsx       # 404 page
+├── (auth)/             # Route group (no URL impact)
+│   ├── login/page.tsx  # /login
+│   └── signup/page.tsx # /signup
+├── api/
+│   └── route.ts        # API handler
+└── _components/        # Private folder (not routed)
+```
+
+## Server Components (Default)
+
+```typescript
+// No directive needed - async by default
+export default async function Page() {
+  const data = await db.query();
+  return <Component data={data} />;
+}
+```
+
+## Server Actions
+
+```typescript
+// app/actions.ts
+"use server";
+
+import { revalidatePath } from "next/cache";
+import { redirect } from "next/navigation";
+
+export async function createUser(formData: FormData) {
+  const name = formData.get("name") as string;
+
+  await db.users.create({ data: { name } });
+
+  revalidatePath("/users");
+  redirect("/users");
+}
+
+// Usage
+<form action={createUser}>
+  <input name="name" required />
+  <button type="submit">Create</button>
+</form>
+```
+
+## Data Fetching
+
+```typescript
+// Parallel
+async function Page() {
+  const [users, posts] = await Promise.all([
+    getUsers(),
+    getPosts(),
+  ]);
+  return <Dashboard users={users} posts={posts} />;
+}
+
+// Streaming with Suspense
+<Suspense fallback={<Loading />}>
+  <SlowComponent />
+</Suspense>
+```
+
+## Route Handlers (API)
+
+```typescript
+// app/api/users/route.ts
+import { NextRequest, NextResponse } from "next/server";
+
+export async function GET(request: NextRequest) {
+  const users = await db.users.findMany();
+  return NextResponse.json(users);
+}
+
+export async function POST(request: NextRequest) {
+  const body = await request.json();
+  const user = await db.users.create({ data: body });
+  return NextResponse.json(user, { status: 201 });
+}
+```
+
+## Middleware
+
+```typescript
+// middleware.ts (root level)
+import { NextResponse } from "next/server";
+import type { NextRequest } from "next/server";
+
+export function middleware(request: NextRequest) {
+  const token = request.cookies.get("token");
+
+  if (!token && request.nextUrl.pathname.startsWith("/dashboard")) {
+    return NextResponse.redirect(new URL("/login", request.url));
+  }
+
+  return NextResponse.next();
+}
+
+export const config = {
+  matcher: ["/dashboard/:path*"],
+};
+```
+
+## Metadata
+
+```typescript
+// Static
+export const metadata = {
+  title: "My App",
+  description: "Description",
+};
+
+// Dynamic
+export async function generateMetadata({ params }) {
+  const product = await getProduct(params.id);
+  return { title: product.name };
+}
+```
+
+## server-only Package
+
+```typescript
+import "server-only";
+
+// This will error if imported in client component
+export async function getSecretData() {
+  return db.secrets.findMany();
+}
+```
+
+## Keywords
+nextjs, next.js, app router, server components, server actions, streaming