The thing we want to solve
Opening a project rarely means opening one app. It can mean an editor, terminal, directories, browser, audio, notifications and workspace organization that exists for a reason.
Work Environments tries to represent that context explicitly. Not as a magic script, and definitely not as “serialize your brain and hope”.
Restore only what can be identified
Activation analyzes capabilities, presents a proposal, then executes. Each item can end as exact, application-owned, approximate, privacy-excluded, failed or unsupported.
- Rules organize windows; they do not launch apps.
- The context can reuse already-running applications.
- Application-native session restoration wins when it exists.
- Private and sensitive contexts are excluded by default.
- Leaving a context never closes work without confirmation.
What is actually feasible
Opening a `.kra`, project directory, editor workspace or terminal working directory is much more realistic than recovering every unsaved piece of text inside every app.
The product needs to show restoration fidelity instead of hiding limitations behind one giant green check.
Sets are still canonical
Current canonical documents define Sets. Work Environments is a product refinement proposal prepared in parallel while Phase 2 remains active.
Until the decision register changes explicitly, backend implementation continues to follow canonical Set semantics. The site shows the direction without pretending the migration already happened.
Current status
There is detailed preparatory design, but this is not an available feature or frozen API. Backend ownership belongs to later phases, and fidelity depends on capabilities exposed by each desktop and application.