La idea que queremos resolver
Abrir un proyecto rara vez significa abrir una sola app. Puede ser editor, terminal, directorios, navegador, audio, notificaciones y una organización de workspace que existe por una razón.
Work Environments intenta representar ese contexto de forma explícita. No como script mágico y mucho menos como “serialicemos tu cerebro y veamos”.
Restaurar solo lo identificable
La activación analiza capacidades, muestra una propuesta y luego ejecuta. Cada item puede acabar exacto, delegado a la app, aproximado, excluido por privacidad, fallido o no soportado.
- Rules organizan ventanas; no lanzan apps.
- El contexto puede reutilizar aplicaciones abiertas.
- La sesión nativa de la app tiene preferencia cuando existe.
- Contextos privados y sensibles quedan fuera por defecto.
- Salir no cierra trabajo sin confirmación.
Lo que sí es viable
Abrir un `.kra`, directorio de proyecto, workspace de editor o terminal en una carpeta es mucho más realista que recuperar cualquier texto jamás guardado dentro de cualquier app.
El producto debe mostrar fidelidad real, no esconder límites detrás de un check verde enorme.
Sets siguen siendo canónicos
Los documentos canónicos actuales definen Sets. Work Environments es una propuesta de refinamiento preparada en paralelo mientras Fase 2 sigue activa.
Hasta que el registro de decisiones cambie explícitamente, el backend sigue la semántica canónica de Sets.
Estado actual
Hay diseño preparatorio detallado, pero no es una función disponible ni una API congelada. Backend y fidelidad pertenecen a fases posteriores y a capacidades reales de cada app y desktop.