Projects & workspace
Everything in Sparkle lives inside a projects. One project is one app you're building, bound to one repository. That's the whole unit. No sprawling config, no mystery state floating between things.
Open a project and you drop into its workspace: your files, the agents working on it, and a live view of exactly what's changing, right now, as it happens. Sparkle records the complete history of every project in git automatically, so you can always rewind and undo. Jump between projects and each one holds its place, untouched, waiting for you.
One project, one app, and a memory that never forgets
Picture a project as a folder for one app you're building. Now picture that folder also remembering every past version of itself, forever. Nothing you make is ever truly lost. Read that again, because it's the thing that lets you experiment without fear.
The workspace is simply what you see when a project is open. Three things, no more: your files, the agents doing the work, and a running list of what's changing as they go. You don't set any of it up. You don't keep it tidy. Sparkle does that, quietly, so you never have to think about it.
Behind the scenes, every meaningful change is saved as a snapshot called a commit on a branch (a line of work). That's git, the version-history tool real builders rely on, working for you without asking you to learn it. Because every step is saved, you can peek at how things were and roll back the moment something looks off. Want the friendly version of the idea? Here's a gentle intro to version control.
Controlling complexity is the essence of computer programming.
That line is the whole job, and Sparkle takes it off your plate. It absorbs the complexity so you can spend your attention on the only thing that matters: what you want to build.
Read the workspace at a glance, juggle projects without losing the thread
One project, one app, one repository. The mental model is clean: a workspace per thing you're building, each with its own files, its own agents, its own history. Switch and you pick up exactly where you dropped that project. Nothing bleeds across, ever.
Reading the workspace fast is the skill that separates the people who ship from the people who babysit. One glance buys you the three signals that matter: which files exist, which agents are live and what they're touching, and the changelog of what's moved since you last looked. Running more than one project at a time? Treat that changing-files view as radar. It tells you who's doing what without opening a single thing.
Here's where the auto-history quietly saves your weekend. Every agent's work gets committed as it goes, on a branch. So when an agent struts off in the wrong direction (and it will), you're not stuck untangling a mess. The change is a discrete commit you inspect and undo. Less "pray it didn't break anything," more "scroll back, roll it back, keep moving."
Repo-bound workspaces, granular commits, clean rollback
A project is a repo-bound workspace: one app, one repository, per-project model and settings. The workspace surfaces repo state, active agents, and per-branch diffs. No global config soup, no leakage between projects. Settings are scoped where they belong.
Sparkle commits agent work incrementally as it runs, so history stays granular and
reviewable instead of landing as one opaque mega-commit you have to reverse-engineer
later. That granularity is the entire payoff: you can git-inspect any agent's output
and roll back to any point when one goes off the rails, without nuking the adjacent
work that was fine. And it's real git underneath. Your commits, real
branches, no sandbox abstraction pretending to be version control.
Switching projects preserves each one's state independently. If you want the canonical treatment: Pro Git on version control.