That is the user model. Existing FLOW, POLICIES, AUDIT, BLUEPRINT and CAPSULE contracts remain underneath for compatibility and advanced work.
Keep the work.
Lose the setup.
A project keeps the objects, one reusable recipe, optional guardrails, explicit runs, bounded history and portable exports together. The underlying FLOW, policy, audit, VAULT and packaging engines stay available without becoming separate things you have to manage first.
Open projects →Keep the object.
Not another copy.
PROJECTS keeps bytes in the existing verified local storage layer, then adds only lightweight labels, project membership and pins.
Browser storage is still local site data. Clearing site data removes unprotected WORKSPACE/VAULT objects.
Current local objects.
Add a file here or continue one from another 2XBR action. Existing verified local items appear automatically.
One project. One operating model.
Project → Recipe → Guardrails → Run → History → Export. FLOW, policy approval, audit evidence and portable packaging stay underneath this one local project surface.
Start a project when work should become repeatable. Objects, recipe, guardrails, runs and exports stay together here.
Saved recipes will appear here. Recipes contain configuration only, never payload bytes.
Objects remain in the verified local VAULT layer. Project records add bounded organization and execution metadata instead of duplicating payload bytes.
A project can recommend the next step, but a run still starts from an intentional action. Guardrailed work keeps its approval boundary and fails closed when that boundary drifts.
Export Template carries reusable definitions; Pack Project carries a bounded portable project copy. Neither turns the local workspace into background cloud sync.