Capturas para documentación

Las capturas deben confirmar un escenario real de usuario. No use datos aleatorios ni información privada.

Datos de demostración

Use un conjunto estable de datos de demostración:

• empleados con roles claros: responsable, ejecutor, coejecutor, observador;
• tareas en distintos estados: nueva, en trabajo, vencida, con checklist, con archivos;
• entidades CRM sin clientes reales;
• documentos con nombres neutrales;
• notificaciones creadas específicamente para el escenario.

Escenas de demostración para tareas

La sección de tareas necesita no una captura universal, sino un conjunto de escenas. Cada escena muestra una situación de trabajo concreta en LadVen OS y debe repetirse en todos los idiomas.

Escena	Qué preparar en LadVen OS	Qué muestra la documentación
task-new	tarea nueva con título, descripción, plazo y responsable	planteamiento correcto del resultado
task-ready-to-work	tarea con participantes, proyecto, cliente, archivos y checklist	contexto completo antes de empezar
task-in-progress	tarea con temporizador activo, comentarios y checklist parcial	ejecución y control actual
task-blocked	tarea con bloqueo en comentarios y riesgo de plazo	cómo fijar obstáculos
task-review	tarea con archivo final y solicitud de aceptación	entrega del resultado al responsable
task-rework	tarea devuelta a corrección con comentario concreto	feedback correcto
task-overdue	tarea vencida en lista y ficha	control de plazos y riesgo de gestión
task-template	plantilla con descripción, roles y checklist	estandarización del trabajo repetible
task-recurring	tarea recurrente con calendario	proceso de calendario sin recordatorio manual
task-automation	regla de automatización con condición y acción	reacción de LadVen OS a un evento del proceso

Primera cola de capturas de tareas

Screenshot ID	Página	Qué capturar
tasks.create-task.details-light-desktop	tasks/create-task.md	formulario de creación con detalles abiertos: plazo, prioridad, estimación, proyecto, cliente
tasks.create-task.participants-light-desktop	tasks/create-task.md	bloque de participantes con iniciador, responsable, coejecutores y observadores
tasks.drawer.progress-light-desktop	tasks/task-drawer.md	ficha en trabajo: checklist parcial, discusión activa, archivos
tasks.drawer.review-light-desktop	tasks/task-drawer.md	ficha en aceptación con archivo final y solicitud de revisión
tasks.comments.blocker-light-desktop	tasks/comments.md	comentario de bloqueo, mención y acción esperada
tasks.list.saved-views-light-desktop	tasks/list-views.md	cortes guardados del responsable: vencidas, aceptación, sin responsable
tasks.list.people-schedule-light-desktop	tasks/list-views.md	planificación por personas para controlar carga
tasks.time.timer-light-desktop	tasks/time.md	ficha o lista con tiempo activo
tasks.close.rework-light-desktop	tasks/close-task.md	devolución a corrección con comentario concreto
tasks.automation.template-light-desktop	tasks/templates-automation.md	plantilla con roles, checklist y criterios
tasks.automation.recurring-light-desktop	tasks/templates-automation.md	tarea recurrente con calendario y plazo
tasks.automation.guard-light-desktop	tasks/templates-automation.md	comprobación de protección antes de cerrar o cambiar estado

Siguiente bloque P0

ID	Qué debe verse	Por qué importa
tasks.kanban.light-desktop	columnas de estado, acumulación en En revisión o En trabajo, responsables y plazos en tarjetas	el responsable ve un cuello de botella del proceso, no solo una lista
tasks.block.bulk-actions.partial-result	cuántas tareas cambiaron, cuáles no se aplicaron, motivos por fila y siguiente paso	la acción masiva exige revisar el resultado, especialmente con permisos y comprobaciones
tasks.surface.automation.rules	condición, acción, alcance y preview de consecuencias	una regla no debe activarse a ciegas; el responsable debe entender la escala
tasks.automation.recurring-light-desktop	calendario, responsable, propietario del proceso, plazo y política de duplicados	la tarea recurrente debe ser un proceso gestionado, no ruido de calendario
tasks.automation.guard-light-desktop	acción restringida, condición incumplida y corrección clara	la comprobación debe explicar cómo llevar la tarea al estado correcto

Reglas

• capture la UI real, no un mockup dibujado;
• verifique pantallas clave en tema claro y oscuro;
• capture mobile para escenarios móviles;
• oculte tokens, URL privadas, nombres reales, teléfonos, emails y datos comerciales;
• guarde las imágenes en la carpeta localizada que corresponda al idioma de la UI;
• añada enlace PNG en Markdown solo junto con estado ready para la misma locale en screenshot-manifest.json.

Localización de capturas

Estándar final: cada captura publicada debe existir en todos los idiomas del portal: ru, en, de, zh, es, fr, kk, ky.

Las capturas se pueden añadir gradualmente, pero la cobertura por idioma debe quedar registrada. Si un escenario ya tiene captura en al menos un idioma, los demás idiomas se registran en screenshot-manifest.json con un estado:

• ready - el archivo existe y se usa;
• planned - la captura es necesaria, pero aún no se tomó;
• blocked - la captura está bloqueada temporalmente, con el motivo en note.

No use capturas de la UI rusa como versión final en páginas de otros idiomas. Solo son aceptables como material temporal de trabajo que no se publica en un artículo localizado.

Si el PNG localizado aún no está capturado, no inserte referencias a la carpeta rusa de imágenes en Markdown traducido. Deje la página sin captura, use un esquema SVG localizado o añada el escenario al plan de capturas.

Nombres de archivo

static/img/es/tasks/create-task/light-desktop.png
static/img/en/tasks/create-task/light-desktop.png
static/img/de/tasks/create-task/light-desktop.png

Qué registrar en el PR

Indique la página de documentación, la ruta del portal, el idioma de la UI, el tema, el breakpoint, la ruta de la captura y el estado en screenshot-manifest.json.