Day brief — 2026-08-07 — ALS-2

1. LOAD — restricciones del día

Anti-patrones a evitar (top del catálogo)

Barra de calidad actual (ratchet)

• Paper: bandas §1–§5, ≥8 artboards UX densos + DS + app + mobile + states.
• Angular alineado a tokens (no default Tailwind genérico).
• API Nest + Prisma + Neon con seed demo usable.
• Smoke: login + list + create (FARMER) + patch status; ng build o serve OK.
• Docs en español, profundidad tipo portfolio (no stubs).

2. BRIEF — concepto del día

Por qué L2 agro (y no otra cosa)

1. Diversidad de sector: la serie no había tocado agricultura; cierra un hueco frente a legal, logística y marketplace.
2. Complejidad L2 justa: dos roles con vistas filtradas, máquina de estados de tarea, creación con parcela implícita y asignación opcional de técnico — suficiente para vertical slice sin multi-tenant ni pagos.
3. Diferenciación vs TROCHA: TROCHA es flota última milla + paradas GPS/ruta; SURCO es cuaderno de explotación (bancales, cultivos, riego/poda/muestreo).
4. Diferenciación vs CORREA: CORREA es marketplace B2C con mascotas y reservas; SURCO es tool interno de finca, sin catálogo ni matching.
5. Metáfora de marca: surco = línea de labranza; el producto “traza” el día de campo en digital sin romanticismo rural kitsch.

Must-have del día (alcance L2)

Explicitamente fuera de alcance (no son deuda del día)

• GPS de parcelas / mapas SIG
• Cuaderno oficial de explotación (compliance legal agro UE)
• Inventario de fitosanitarios / trazabilidad normativa
• Multi-explotación / multi-tenant
• Notificaciones push / WhatsApp
• App nativa offline-first completa
• Pagos, marketplace de insumos, clima API

3. Directivas activas aplicadas

4. Cuentas demo

Seed de referencia: parcelas Bancal Nord (olivo arbequina 2,4 ha) y Surco Baix (almendro 1,1 ha); 5 FieldTask con códigos SU-MMDD-XX.

Supuestos (no investigación primaria)

• Explotaciones familiares mediterráneas coordinan con libreta/WhatsApp.
• Técnico externo de asesoramiento visita varias fincas.
• Conectividad intermitente en campo (offline full = out of scope v1).

5. Criterio de cierre del día

• Brief de diversidad y anti-patrones documentado
• Producto definido (no marketplace, no GPS fleet)
• Implementación runnable API :3007 / web :4200
• Documentación portfolio 00–20 + presentation + README
• Paper file enlazado y referenciado por bandas
• Hipótesis vs investigación marcadas (sin stats falsas)

Estado del brief: listo para EXECUTE y entrega de caso.

Referencia Paper — SURCO

1. Mapa de canvas (bandas jerárquicas)

Layout canvas (referencia): origen (0,0) · gaps ~80px · bandas Y orientativas: UX ~100 / Design ~2180 / App ~3980 / States ~5280.

2. Inventario de artboards

§1 — UX PROCESS

§2 — DESIGN + PUBLIC

§3 — APP (desktop)

§4 — MOBILE

§5 — STATES

3. Checklist de densidad (anti thin-frames)

4. Mapeo Paper → Angular

5. Tokens de diseño en Paper

Nota implementación: tailwind.config.js de la app usa valores muy cercanos (#F3F0E8, #3A5A40, #C4A574) para legibilidad en pantalla; la fuente de verdad de marca del caso es la tabla superior.

6. Enlaces

• Paper: https://app.paper.design/file/01KZDGF3509TA4WDZTTQJW1V45
• Case: /Users/cristian/orca/ux-projects/2026-08-07-surco/
• App: /Users/cristian/orca/surco-app/
• Neon project: old-paper-48739086

01 — Definición de proyecto — SURCO

1. Identidad

2. Problema

Principal (hipótesis de diseño)

Las explotaciones familiares coordinan riego, poda, muestreos y revisiones de plagas con libretas, notas en el móvil y hilos de WhatsApp. No hay un estado compartido de la tarea ni un historial por parcela que agricultor y técnico vean a la vez.

Secundarios

Supuestos (no investigación primaria propia)

• S1: En fincas familiares pequeñas–medianas (1–5 parcelas activas), la coordinación se hace sin software de gestión agrícola enterprise.
• S2: El técnico de campo (asesor o empleado) necesita una lista corta de asignaciones, no un ERP.
• S3: El valor inmediato está en estado de tarea + parcela + due date, no en SIG ni compliance legal del cuaderno oficial.

Hipótesis de producto

No se afirman estadísticas de mercado inventadas. Todo lo anterior es razonamiento de diseño etiquetado.

3. Propuesta de valor

No es SURCO

4. Objetivos

Negocio / caso de estudio

• Demostrar vertical slice L2 agro con JWT multi-rol y dominio Parcel/FieldTask.
• Portfolio coherente: Paper + docs + app runnable.

Usuario

No objetivos v1 (explícitos)

• Mapas y geocercas
• Inventario de productos fitosanitarios
• Facturación o costes por tarea
• Chat in-app
• Roles ADMIN / multi-finca

5. Roles y permisos (resumen)

6. Métricas (modelo, no instrumentadas en v1 salvo base)

7. Alcance funcional v1 (L2)

8. Criterios de aceptación de producto

1. Un FARMER puede iniciar sesión y ver solo sus tareas ordenadas por dueAt.
2. Un TECHNICIAN ve solo tareas donde technicianId = su id.
3. Crear tarea exige título, nombre de parcela y fecha; opcional técnico por email → status ACTIVE.
4. El detalle muestra código, parcela, cultivo, ha, notas y permite cambiar estado.
5. Sin token, las rutas /api/tasks* responden 401.
6. La home comunica “cuaderno”, no marketplace ni flota.

9. Stack y artefactos

10. Riesgos y mitigaciones

11. Glosario

02 — Estrategia de investigación UX — SURCO

Importante: este documento contiene artefactos de diseño y razonamiento secundario.
No hay entrevistas de campo primarias ni estadísticas inventadas presentadas como dato medido.
Etiquetas: [COMPROBADO] en producto, [SUPUESTO], [HIPÓTESIS], [DECISIÓN DE DISEÑO].

1. Objetivos de investigación (del caso)

2. Fuentes y límites

Fuentes admisibles (secundarias / operativas)

• Conocimiento general de digitalización agro (cuadernos de campo, asesoramiento técnico).
• Analogía operativa con herramientas de tareas multi-rol ya validadas en la serie (FIRME casos, TROCHA paradas, SENDA visitas) — no copiar dominio.
• Restricciones ALS-2 de diversidad (sector agro libre; no marketplace; no GPS fleet).

Límites éticos de verdad

3. Stakeholders

Mapa de poder (resumen)

• Decisor de adopción: FARMER (titular de la explotación).
• Usuario frecuente en campo: TECHNICIAN (y a veces el propio farmer).
• Riesgo de rechazo: si la app pide más datos que un WhatsApp sin devolver claridad de estado.

4. Personas

P1 — Inés Roura · FARMER

Escenario: Por la mañana crea “Riego gota a gota” en Bancal Nord, asigna a Pol, y por la tarde comprueba DONE.

P2 — Pol Vidal · TECHNICIAN

Escenario: Abre SURCO en el móvil, ve ACTIVE, ejecuta, pasa a DONE.

Anti-persona

5. JTBD y user stories

Job principal

Cuando hay trabajos de parcela que deben hacerse esta semana,
quiero registrarlos con parcela, fecha y responsable,
para que el campo quede al día sin perseguirse por WhatsApp.

Jobs secundarios

Stories Must (v1)

Should / Could (fuera de L2 del día, no deuda)

• Selector de parcela existente (vs texto libre).
• Filtros por estado en UI.
• Adjuntos foto de plaga.
• Offline queue.

6. Journey — día de Inés (happy path)

Journey — Pol (campo)

Login → Mis asignaciones → Detalle → ACTIVE (si aplica) → DONE → siguiente tarea.

7. Service blueprint (simplificado)

8. Hallazgos → requisitos → features

9. Preguntas abiertas (investigación futura real)

1. ¿Cuántas tareas activas gestiona una finca familiar en semana de riego?
2. ¿El técnico es empleado fijo o asesor multi-finca? (impacta multi-tenant)
3. ¿Qué % del tiempo de campo hay cobertura de datos? (offline)
4. ¿Necesitan export PDF para subvenciones? (compliance)

Estas preguntas no bloquean el L2; informan un posible L3.

10. Plan de validación post-caso (opcional)

Estado actual: validación de diseño + smoke técnico del vertical slice; no estudio de campo primario.

03 — Arquitectura de información — SURCO

1. Principios de IA

2. Sitemap

/                          Home (público)
/login                     Login JWT
/app/tasks                 Lista + stats (auth)
/app/tasks/new             Nueva tarea (auth · FARMER)
/app/tasks/:id             Detalle + estado (auth · parte)
/**                        → redirect /

Árbol por audiencia

3. Navegación

Pública

App (autenticada)

No hay menú lateral multi-sección en v1 (evita IA de ERP).

4. Inventario de contenido

5. Taxonomía y etiquetas de estado

Orden de lista: por dueAt ascendente (lo que vence antes, primero).

6. Modelo mental vs UI

7. Permisos y objetos

User 1──* Parcel (farmerId)
User 1──* FieldTask (farmerId)
User 0..1──* FieldTask (technicianId opcional)
Parcel 1──* FieldTask

8. Flujos de información entre roles

1. FARMER crea tarea (+ opcional email técnico) → si hay técnico válido, ACTIVE.
2. TECHNICIAN lista solo asignadas → actualiza a DONE.
3. FARMER ve el cambio en list/detail (mismo recurso).

No hay bandeja de notificaciones: el “pull” es abrir el cuaderno.

9. SEO / URLs (público)

10. Criterios de aceptación IA

1. Desde home, un usuario llega a login en 1 click.
2. Tras login válido, aterriza en lista de tareas.
3. Ninguna ruta de app asume rol incorrecto en la nav (sin “+ Tarea” para técnico).
4. Detalle y new son hijos semánticos de tasks (path prefix /app/tasks).
5. No existen secciones huérfanas (inventario, mapa, chat) en la nav.

04 — Flujos de usuario — SURCO

Convenciones

• Actor: FARMER | TECHNICIAN | Guest
• Éxito: resultado observable
• Errores: UI + código HTTP cuando aplica

F1 — Descubrimiento y entrada (Guest)

Home (/) → CTA "Abrir cuaderno" | "Entrar" | "Soy agricultor/técnico"
        → Login (/login)

Éxito: formulario de login visible.
No hay registro público en v1 (solo seed).

F2 — Login JWT

/login → POST /api/auth/login { email, password }
      → 200 { accessToken, user } → localStorage → /app/tasks
      → 401 → mensaje error en form

Éxito: token guardado; user con role FARMER o TECHNICIAN.
Errores:

F3 — Listar tareas + stats

/app/tasks (guard token en cliente)
  → GET /api/tasks
  → GET /api/tasks/stats/summary
  → Render cards + 4 métricas

Orden: dueAt ASC.
Include: farmer, technician, parcel.

Variantes de UI

AC:

1. Sin token → redirect /login.
2. Técnico no ve botón “+ Tarea”.
3. Stats open = PENDING + ACTIVE.

F4 — Crear tarea (solo FARMER)

/app/tasks → + Tarea → /app/tasks/new
  → submit → POST /api/tasks
  → 201/200 task → navegar a lista o detalle
  → 403 si TECHNICIAN

Campos

Lógica de negocio

1. Buscar parcela del farmer por name; si no existe, crear con hectares: 1 y crop dado.
2. Si technicianEmail: buscar user role TECHNICIAN; si no, 404 “Técnico no encontrado”.
3. Generar code = SU- + MMDD + - + random 100–999.
4. Status inicial: PENDING sin técnico; ACTIVE con técnico.

Errores:

AC: FARMER con datos válidos ve la nueva tarea en la lista ordenada por dueAt.

F5 — Detalle y cambio de estado

/app/tasks/:id
  → GET /api/tasks/:id
  → usuario elige nuevo status
  → PATCH /api/tasks/:id/status { status }
  → UI actualiza badge

Permisos get

Permisos patch (resumen API)

• Debe ser parte (mismas reglas que get).
• TECHNICIAN: status permitido en subconjunto ACTIVE | DONE | CANCELLED (no impone PENDING según guard de servicio).
• FARMER: puede actualizar status de sus tareas (incluye cancelar).

Transiciones de diseño (happy)

PENDING ──► ACTIVE ──► DONE
    │           │
    └───────────┴──► CANCELLED

AC: tras DONE, la lista muestra badge “Hecha” y stats HECHAS incrementa al refrescar.

F6 — Logout

Click Salir → clear token/user → /login

AC: volver a /app/tasks redirige a login.

F7 — Flujos de error transversales

Diagrama resumen ( Mermaid )

flowchart TD
  H[Home] --> L[Login]
  L -->|JWT OK| T[Tasks list]
  L -->|401| L
  T -->|FARMER| N[New task]
  N -->|POST| T
  T --> D[Detail]
  D -->|PATCH status| D
  T -->|logout| L

Matriz flujo × rol

05 — Modelo de datos — SURCO

1. Visión general

Dominio mínimo de cuaderno de campo L2:

Base: PostgreSQL (Neon) · ORM: Prisma · IDs: cuid().

2. Enums

Role

TaskStatus

3. Diagrama ER (texto)

User ─────────────┬────────── Parcel
  id              │            id
  email           │            name
  passwordHash    │            crop
  name            │            hectares
  role            │            farmerId ──► User.id
                  │
                  ├────────── FieldTask (as farmer)
                  │            id, code, title, notes
                  │            status, dueAt
                  │            farmerId ──► User.id
                  │            technicianId? ──► User.id
                  │            parcelId ──► Parcel.id
                  │
                  └────────── FieldTask (as technician)

4. Tablas / modelos Prisma

User

Parcel

FieldTask

5. Reglas de integridad y negocio

6. Seed de referencia (2026-08-07)

Códigos ejemplo: SU-0807-01 … SU-0807-05 (el prefijo de fecha depende del día de seed).

7. Contratos API ↔ modelo

POST /api/auth/login

In: { email, password }
Out: { accessToken, user: { id, email, name, role } }

GET /api/tasks

Out: FieldTask[] con parcel, farmer, technician.

GET /api/tasks/stats/summary

Out:

{
  "total": 5,
  "open": 4,
  "byStatus": { "PENDING": 2, "ACTIVE": 2, "DONE": 1, "CANCELLED": 0 }
}

POST /api/tasks

In:

{
  "title": "Riego gota a gota",
  "parcelName": "Bancal Nord",
  "crop": "Olivo arbequina",
  "dueAt": "2026-08-08T08:00:00.000Z",
  "notes": "2 h sector A",
  "technicianEmail": "tecnico@surco.agro"
}

Out: FieldTask creado (status ACTIVE si técnico OK).

PATCH /api/tasks/:id/status

In: { "status": "DONE" }
Out: FieldTask actualizado.

GET /api/tasks/:id

Out: un FieldTask con relaciones; 403/404 según acceso.

8. Índices y escalado (notas)

v1 no define índices extra más allá de PK/unique Prisma.

9. Privacidad de datos (enlace a doc 11)

• Email y nombre son datos de cuenta demo.
• Notas de tarea pueden contener info operativa de finca: no loguear bodies en claro en producción.
• No se almacenan coordenadas GPS ni datos de salud vegetal sensibles más allá de texto libre.

10. Criterios de aceptación de datos

1. Migración init aplica User, Parcel, FieldTask + enums.
2. Seed es idempotente en la práctica (deleteMany + create).
3. No se puede insertar FieldTask sin parcelId y farmerId válidos (FK).
4. code único impide colisiones exactas (retry no implementado; probabilidad baja con random 100–999).

06 — Stack tecnológico — SURCO

1. Resumen

Stack fijo de la serie ALS-2: no se sustituye Angular/Nest/Neon/Tailwind sin excepción documentada.

2. Estructura monorepo app

surco-app/
├── package.json          # scripts api / web / db:*
├── apps/
│   ├── api/
│   │   ├── prisma/
│   │   │   ├── schema.prisma
│   │   │   ├── seed.ts
│   │   │   └── migrations/
│   │   ├── src/
│   │   │   ├── main.ts
│   │   │   ├── app.module.ts
│   │   │   ├── auth/
│   │   │   ├── tasks/
│   │   │   └── prisma/
│   │   └── package.json
│   └── web/
│       ├── src/app/
│       │   ├── pages/ (home, login, tasks, task-detail, task-new)
│       │   ├── core/api.service.ts
│       │   └── app.routes.ts
│       ├── tailwind.config.js
│       └── package.json
└── README.md

Decisión: apps independientes (npm --prefix), sin npm workspaces que rompan Angular (directiva D-P1-03).

3. Puertos y entornos

Variables típicas API (.env):

4. Backend — módulos

Endpoints

CORS: habilitado para dev web en :4200 (según main.ts).

5. Frontend — arquitectura

Rutas

6. Diseño → código

7. Scripts npm (raíz app)

npm run api        # Nest start:dev :3007
npm run web        # ng serve :4200
npm run db:migrate # prisma migrate
npm run db:seed    # seed demo

Instalación:

npm install --prefix apps/api
npm install --prefix apps/web

8. Seguridad técnica (resumen; ver doc 11)

9. Observabilidad

v1: logs Nest por defecto; sin APM. Errores de UI se muestran como copy al usuario. Analytics de producto: doc 12 (modelo).

10. Criterios de aceptación técnicos

1. npm run api levanta en 3007 y responde login seed.
2. npm run web sirve en 4200 y consume API.
3. Prisma migrate + seed generan 2 users y 5 tasks.
4. ng build (o serve) sin errores de compilación.
5. Rutas de tasks sin JWT → 401.

07 — Dirección creativa — SURCO

1. Posicionamiento visual

2. Concepto de marca

SURCO es la línea que el arado deja: orden en la tierra.
El producto traza el mismo orden en digital: parcelas, tareas, estados.

3. Moodboard verbal

1. Mañana en el bancal, luz lateral, polvo fino.
2. Libreta de campo con mancha de tierra en el borde — traducida a UI limpia.
3. Verde olivo y hueso de almendra; metal de grifo de riego solo como detalle.
4. Silencio operativo: pocos colores, muchas decisiones claras.

4. Fotografía y media

Anti-patrón: rectángulos grises con título (D-P0-02).

5. Sistema tipográfico (dirección)

Jerarquía orientativa:

6. Color — dirección de marca

7. Forma y layout

8. Motion (mínimo)

v1 sin librería de motion. Transiciones nativas:

• Hover borde card → primary/40
• Botones hover primary-strong
• Sin spinners custom obligatorios (loading textual aceptable)

9. Diferenciación en la serie diaria

10. Criterios de aceptación creativos

1. Home reconoce SURCO en <3 s (wordmark + eslogan + hero agro).
2. No se confunde con app de delivery ni pet-care.
3. CTAs “Soy agricultor / Soy técnico” alineados al modelo multi-rol.
4. Estado de tareas legible por color+texto (no solo color).
5. Consistencia Paper ↔ Angular en tokens y tipografía.

08 — Design system — SURCO

1. Fundamentos

2. Color tokens

Marca (fuente de verdad del caso)

Mapeo Tailwind app

3. Tipografía

4. Espaciado y radio

5. Componentes

5.1 Botones

Estados: default · hover (strong) · disabled (opacidad) · focus visible ring.

5.2 Badges de estado

Regla a11y: no codificar solo con color; siempre texto del label.

5.3 Cards de tarea

Estructura:

1. Meta: code · parcel.name (straw, xs bold)
2. Título (lg semibold)
3. Cultivo · hectáreas
4. Vence + nombre contraparte
5. Badge status (trailing)

Interacción: bloque entero es enlace a detalle; hover border primary/40.

5.4 Stats tiles

Grid 2×2 mobile / 4 col desktop: TOTAL, ABIERTAS, ACTIVAS, HECHAS.
Número en Literata 2xl; label 11px bold muted.

5.5 Forms

Campos new task: title, parcelName, crop, dueAt, notes, technicianEmail.

5.6 Header app

Logo display · badge rol · nombre · (+ Tarea) · Salir.

5.7 Empty state

Borde dashed, texto centrado, CTA “Crear la primera →” si FARMER.

5.8 Error inline

Párrafo o banner; mensaje accionable (“No se pudieron cargar las tareas.”).

6. Iconografía

v1 sin set de iconos denso. Preferir:

• Texto y tipografía
• Badges
• Emojis no usados en UI profesional

Si se añaden iconos: stroke 1.5–2, color ink/primary, 20–24px.

7. Elevación

8. Breakpoints (orientativos Tailwind)

Touch targets: ≥44px en CTAs móviles (doc 10).

9. Do / Don’t

10. Criterios de aceptación DS

1. Tokens documentados y reflejados en Tailwind.
2. Primary contrast aceptable sobre blanco (leaf oscuro).
3. Empty y error reutilizan patrones de card/borde.
4. Paper B-0 y UI Angular no divergen en familia tipográfica ni clima de color.

09 — Guía de contenido — SURCO

1. Voz y tono

Principios

1. Preferir hacer sobre gestionar (“Crear tarea”, no “Gestionar ítems”).
2. Usar dominio real: parcela, bancal, riego, poda, muestreo.
3. Evitar anglicismos de producto genérico (dashboard, pipeline, owner).
4. No infantilizar al agricultor ni romanticizar la ruralidad.
5. Demo credentials visibles donde ayuden al portfolio (footer home).

2. Nombres de producto

3. Microcopy por pantalla

Home

Login

Lista FARMER

Lista TECHNICIAN

Stats labels

TOTAL · ABIERTAS · ACTIVAS · HECHAS

Detalle

Nueva tarea

Errores de carga

• “No se pudieron cargar las tareas.”
• “No se pudo guardar la tarea.”
• “Técnico no encontrado.” (API)

Estados (labels)

4. Estilo de códigos y datos

5. Mensajes que no deben aparecer

6. Accesibilidad de contenido

• Alt hero descriptivo en español.
• Errores asociados a campos cuando sea form.
• No usar solo color para “Activa”.
• Evitar mayúsculas largas en párrafos (solo eyebrows).

7. Criterios de aceptación de contenido

1. Home y app usan el eslogan oficial.
2. Empty de farmer incluye camino a crear.
3. Credenciales demo coherentes en README, seed y footer.
4. Labels de estado en español en toda la UI.

10 — Accesibilidad — SURCO

1. Objetivo

Cumplir un nivel WCAG 2.2 AA razonable en el vertical slice web, priorizando:

• Contraste de texto y CTAs
• Navegación por teclado
• Nombres accesibles en controles
• Estados no solo por color
• Formularios con errores comprensibles

Contexto de uso: móvil en exterior (técnico) y desktop (planificación). El brillo solar y guantes no se resuelven del todo en web, pero se mitigan con targets grandes y contraste alto leaf/bone.

2. Alcance

3. Contraste

Regla: si un acento straw no alcanza contraste en body, no usarlo para texto < 18px esencial.

4. Teclado y foco

Focus visible: outline del navegador o ring Tailwind; no outline: none global.

5. Semántica y estructura

Imágenes:

• Hero: alt="Parcelas agrícolas al atardecer"
• Decorativas: vacías solo si no aportan (evitar en v1)

6. Formularios

7. Color y estado

8. Touch y móvil de campo

9. Movimiento y media

• Sin autoplay de vídeo.
• Sin animaciones esenciales para entender estado.
• Respeto futuro a prefers-reduced-motion si se añaden transitions largas.

10. Pruebas recomendadas

11. Criterios de aceptación

1. Login completible solo con teclado.
2. Mensajes de error legibles y en español.
3. Estados de tarea con texto, no solo color.
4. Hero con alt no vacío.
5. No hay outline: none sin reemplazo de foco.

11 — Privacidad y seguridad — SURCO

1. Contexto

SURCO es un demo de portfolio / vertical slice de cuaderno de campo.
Trata datos de cuenta y notas operativas de finca. No es un producto certificado en producción, pero el diseño aplica controles mínimos serios (JWT, bcrypt, autorización por rol).

No se declara cumplimiento RGPD/LOPDGDD definitivo: en producción real se requieren política de privacidad, base legal documentada y, si hay encargados, DPA.

2. Datos tratados

No se tratan en v1: ubicación GPS, biometría, datos de salud personal, pagos, documentos de identidad, geolocalización de parcelas.

3. Base legítima (modelo producto real)

Si SURCO fuera producción en UE:

Demo: datos seed ficticios; no usar emails reales de terceros sin consentimiento.

4. Controles de seguridad

Matriz de autorización (resumen)

5. Amenazas y mitigaciones

6. Retención y borrado (modelo / hipótesis de producto)

v1 no expone endpoint de borrado de cuenta (fuera de alcance).

7. Cookies y tracking

• Auth en localStorage (token), no cookie de sesión.
• Sin banners de analytics de terceros en v1.
• Si se añade analytics (doc 12), minimización IP y consentimiento según base legal.

8. Roles y principio de mínimo privilegio

• TECHNICIAN no crea tareas ni ve tareas de otros farmers no asignadas.
• No hay rol ADMIN en v1 (reduce superficie).
• Parcelas solo del farmer propietario.
• Email de técnico opcional en create: único PII de “tercero” ligero en el flujo.

9. Incidentes (proceso demo)

1. Rotar JWT_SECRET y forzar re-login.
2. Reset seed / rotar passwords demo.
3. Revisar logs Nest y Neon.
4. Notificar usuarios afectados si hubiera PII real.
5. Documentar en memory si afecta al caso.

10. Criterios de aceptación seguridad

1. Password no se almacena en claro.
2. /api/tasks sin Bearer → 401.
3. TECHNICIAN POST /api/tasks → 403.
4. TECHNICIAN GET tarea de otro → 403.
5. .env con DATABASE_URL no versionado en repo público (revisar .gitignore).
6. No se loguean contraseñas ni tokens completos en cliente.

12 — Analytics y métricas — SURCO

1. Propósito

Definir qué medir para validar el cuaderno multi-rol.
v1 implementa stats de dominio (GET /api/tasks/stats/summary) y deja el plan de producto analytics listo; no requiere un vendor concreto (Plausible/GA/etc.) para cerrar el L2.

No se inventan tasas de conversión reales: instrumentar en post-MVP; las cifras de producto son objetivos de modelo, no resultados medidos de campo.

2. North Star y métricas de producto

3. Funnel UX (modelo)

Home view → Login submit → Login success → List view → Create start → Create success → Status DONE

4. Stats in-product (implementado)

GET /api/tasks/stats/summary devuelve:

UI: tiles TOTAL / ABIERTAS / ACTIVAS / HECHAS en lista.

Limitación: no es serie temporal; es snapshot del scope del usuario.

5. Segmentos

6. Privacidad en medición

7. Tablero ops (hipótesis de lectura)

1. Operación semanal: DONE, open, ACTIVE.
2. Funnel activación FARMER.
3. % con técnico asignado.
4. Salud API: latencia p95 login/list/create.
5. Empty rate post-login (usuarios sin tareas).

8. Alertas (modelo)

9. Lo que no medimos en v1

• Heatmaps
• Session replay
• A/B testing
• Attribution marketing multi-canal
• Tasas de conversión inventadas presentadas como reales

10. Enlace a hipótesis (doc 02)

11. Criterios de aceptación

1. Stats summary coherente con conteo de lista del mismo usuario.
2. Documentado el North Star y funnel aunque el vendor no esté cableado.
3. Ningún evento planeado incluye contenido libre de notes.
4. Hipótesis H1–H3 enlazan a métricas de esta doc.
5. Sin stats de mercado falsas en el case.

13 — Plan de QA y pruebas — SURCO

1. Objetivo

Verificar el vertical slice L2 end-to-end: auth multi-rol, listado filtrado, creación, cambio de estado, empty/error, build runnable.

2. Entorno de prueba

3. Smoke crítico (bloqueante de cierre)

Smoke ejecutado / diseñable (2026-08-07)

4. Casos funcionales por área

4.1 Auth

4.2 Tareas farmer

4.3 Tareas technician

4.4 UI / contenido

5. Pruebas API (ejemplos curl)

# Login
curl -s -X POST http://localhost:3007/api/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"campo@surco.agro","password":"password123"}'

# List (TOKEN=...)
curl -s http://localhost:3007/api/tasks -H "Authorization: Bearer $TOKEN"

# Stats
curl -s http://localhost:3007/api/tasks/stats/summary -H "Authorization: Bearer $TOKEN"

# Create
curl -s -X POST http://localhost:3007/api/tasks \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"title":"Test riego","parcelName":"Bancal Nord","dueAt":"2026-08-10T08:00:00.000Z"}'

# Status
curl -s -X PATCH http://localhost:3007/api/tasks/$ID/status \
  -H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
  -d '{"status":"DONE"}'

6. Regresión visual (manual)

Comparar con Paper §2–§5 (file 01KZDGF3509TA4WDZTTQJW1V45).

7. Accesibilidad spot-check

Ver doc 10: teclado login+create, contraste botones, alt hero, labels estado.

8. Regresión de datos

• Seed idempotente (deleteMany + create).
• Migración Prisma deploy limpia.
• Códigos SU-* únicos en seed y creates.

9. Criterios de salida (release demo)

• Smoke S1–S10 en verde
• Seed reproducible
• README con puertos 3007/4200
• Sin secretos en cliente más allá de JWT de sesión
• Docs case actualizados

10. Bugs conocidos / límites aceptados v1

No son fallos de cierre si están documentados y el smoke pasa.

14 — Handoff a desarrollo — SURCO

1. Fuentes de verdad

2. Arranque local

cd /Users/cristian/orca/surco-app
cp apps/api/.env.example apps/api/.env   # si existe; configurar DATABASE_URL + JWT_SECRET
npm install --prefix apps/api
npm install --prefix apps/web
npm run db:migrate
npm run db:seed
npm run api    # :3007
npm run web    # :4200

Demo: campo@surco.agro / tecnico@surco.agro · password123

3. Mapa de pantallas → código

4. Mapa API → código

5. Contratos (resumen)

Login request/response

// POST /api/auth/login
{ "email": "campo@surco.agro", "password": "password123" }

// 200
{ "accessToken": "<jwt>", "user": { "id": "...", "email": "...", "name": "Inés Roura", "role": "FARMER" } }

Create task

{
  "title": "string min 3",
  "parcelName": "string min 2",
  "crop": "optional string",
  "dueAt": "ISO-8601",
  "notes": "optional",
  "technicianEmail": "optional email"
}

Status

{ "status": "PENDING" | "ACTIVE" | "DONE" | "CANCELLED" }

6. Reglas de negocio a no romper

1. Solo FARMER crea tareas.
2. List/get filtrados por rol (no “list all”).
3. Parcela se resuelve por nombre + farmerId.
4. Técnico válido → status inicial ACTIVE.
5. Código SU-… único.
6. TECHNICIAN no fuerza estados fuera de su subconjunto permitido en service.

7. Checklist de paridad Paper ↔ app

8. Definition of Done (feature nueva)

• Endpoint con DTO + authz
• UI con tokens SURCO (no gris genérico)
• Empty/error si aplica
• Seed o fixture actualizado
• Doc 04/05 tocados si cambia flujo o modelo
• Smoke del flujo en QA 13

9. Deuda técnica conocida (no alcance L2 bloqueante)

10. Contacto de decisión de producto

Para cambios de alcance L2 vs L3: ver docs/00-day-brief.md y docs/15-roadmap.md.
No reintroducir marketplace ni GPS fleet sin cambio explícito de brief de diversidad.

15 — Roadmap — SURCO

1. Principio

El L2 del 2026-08-07 está cerrado (auth, tareas, estados, docs, Paper, seed).
Este roadmap lista evoluciones de complejidad (L2+ / L3), no deudas del día.

2. Ahora — v1 entregada (L2)

3. Next — endurecer L2 (opcional, misma complejidad)

4. Later — L3 posible (nueva decisión de brief)

Solo si un día futuro elige agro L3 (y diversidad lo permite):

5. No roadmap (explícito)

6. Hitos sugeridos (si hubiera continuidad de producto)

7. Dependencias externas

• Neon disponibilidad
• Paper para iteración UI
• Posible object storage si fotos L3

8. Criterio para abrir L3

1. Diversidad ALS-2 lo permite (no repetir sector/tipo en cooldown).
2. Hipótesis H1 validada o refutada con uso real.
3. Capacidad de cerrar offline o multi-tenant en una iteración si se declara en alcance.

16 — Especificaciones de interacción — SURCO

1. Principios de interacción

2. Home

3. Login

Timing: feedback de error inmediato al 401; sin toast global obligatorio.

4. Lista de tareas

Stats

Solo lectura; no filtran la lista al click (v1). Futuro: click ACTIVE filtra.

5. Nueva tarea

Validación: bloquear submit vacío en cliente si se desea; servidor es autoridad.

6. Detalle y estados

Feedback

• Success: cambio visible del badge (sin modal).
• Error patch: mensaje “No se pudo actualizar el estado.”

7. Transiciones de estado (UX)

8. Responsive

9. Gestos y no-gestos

• No swipe-to-done en v1.
• No drag and drop de prioridades.
• No long-press menús.

10. Criterios de aceptación interacción

1. Create → visible en lista sin pasos ocultos.
2. DONE en ≤3 interacciones desde lista (abrir → acción → hecho).
3. Técnico nunca ve CTA create.
4. Errores no silenciosos.

17 — Mapa de prototipo — SURCO

1. Qué es el prototipo

Paper no expone prototipo clicable nativo vía MCP; la app es el prototipo navegable.

2. Enlaces

3. Flujos clicables en app

4. Mapa de hotspots (Paper → app)

5. Datos del prototipo

Usar seed (no inventar usuarios en UI):

• Parcelas: Bancal Nord, Surco Baix
• Tareas: riego, plagas, poda, suelo, abonado
• Roles: FARMER / TECHNICIAN

Reset: npm run db:seed.

6. Guión de demo (3 minutos)

1. Home: eslogan y pasos (20 s).
2. Login Inés (20 s).
3. Stats + lista (20 s).
4. Crear “Revisión de goteros” en Bancal Nord, asignar Pol (40 s).
5. Logout → login Pol (20 s).
6. Abrir tarea y marcar Hecha (30 s).
7. Logout; mencionar Paper y stack (30 s).

7. Limitaciones del prototipo

8. Criterios de aceptación del mapa

1. Cada pantalla Paper §2–§5 tiene ruta o estado app equivalente.
2. Demo de 3 min cubre ambos roles.
3. README enlaza Paper + cómo correr app.

18 — Auditoría de completitud — SURCO (2026-08-07)

1. Alcance auditado

Vertical slice L2: cuaderno parcelas/tareas multi-rol FARMER+TECHNICIAN, con docs, Paper, Angular+Nest+Prisma+Neon.

2. Checklist CRON / ALS-2

3. Cobertura funcional

4. Cobertura Paper

5. Rúbrica de calidad (auto SCORE orientativo)

6. Huecos aceptados (no regresiones de cierre)

7. Veredicto

COMPLETO para entrega de caso 2026-08-07 tras documentación portfolio y app alineada al brief.
Cualquier ampliación multi-tenant/GPS/marketplace requiere nuevo brief de diversidad, no parche silencioso.

19 — Backlog completo — SURCO

Inventario de ítems. Los del alcance L2 del día están Done.
El resto es opcional / siguiente nivel, no deuda oculta del cierre §1.1.

1. Done — L2 (2026-08-07)

2. Backlog L2+ (misma complejidad, mejoras)

3. Backlog L3 (requiere brief nuevo)

4. Explicitamente no-backlog

5. Orden de ataque recomendado (si hay continuidad)

1. B01 guards + B06 e2e
2. B03 selector parcelas
3. B02 filtros
4. Evaluar brief L3 solo tras uso real

6. Trazabilidad

20 — Implementación — SURCO

1. Resumen ejecutivo técnico

2. Cómo arrancar

cd /Users/cristian/orca/surco-app
npm install --prefix apps/api
npm install --prefix apps/web
# Configurar apps/api/.env con DATABASE_URL y JWT_SECRET
npm run db:migrate
npm run db:seed
npm run api   # http://localhost:3007
npm run web   # http://localhost:4200

Credenciales

3. Módulos API implementados

Auth

• POST /api/auth/login
• Valida email/password; compara bcrypt; emite JWT con sub, email, role.
• JwtStrategy + JwtAuthGuard protegen tasks.

Tasks

Prisma

Enums Role, TaskStatus; modelos alineados a doc 05; migración init; seed con 2 parcelas y 5 tareas.

4. Frontend implementado

ApiService centraliza base URL, token storage, métodos HTTP tipados (FieldTask, TaskStats, User).

5. Decisiones de implementación

6. Variables de entorno

Web: URL de API configurable en service (default localhost:3007).

7. Smoke de implementación (mínimo)

1. Seed OK en consola (SURCO seed OK).
2. Login farmer 200.
3. List length ≥ 1.
4. Create task 201/200.
5. Login tech ve tarea si asignada.
6. Patch DONE 200.
7. Web muestra badges en español.

8. Estructura de ficheros clave

apps/api/src/main.ts
apps/api/src/auth/*
apps/api/src/tasks/*
apps/api/prisma/schema.prisma
apps/api/prisma/seed.ts
apps/web/src/app/app.routes.ts
apps/web/src/app/core/api.service.ts
apps/web/src/app/pages/**/**
apps/web/tailwind.config.js
apps/web/src/styles.css

9. Despliegue (notas)

No obligatorio para cierre local del case. Sugerencia:

10. Criterios de aceptación de implementación

1. Comandos del README reproducen el entorno.
2. Ambos roles demuestran flujos distintos.
3. 403/401 correctos en pruebas de authz.
4. UI usa tokens de marca (no default blue Tailwind).
5. Case docs enlazan Paper, Neon id, puertos y demos.