Project-Scoped State and Activity

Original Problem

Some Studio state is global by nature, but some state is clearly tied to one opened project.

If project-local state is stored as if it were application-global, the shell starts mixing unrelated histories and the project root stops being the obvious home of Studio-owned project data.

Consolidated Decision

The stable direction is:

project-local Studio state lives under .studio/ inside the project root;
shell activity is restored and persisted per project;
persisted activity history is bounded;
.studio/ is the reserved root for future project-local Studio settings.

Final Model

1. Storage Root

each project owns .studio/;
new-project scaffolding creates that directory;
.workspace/ is not the project-local Studio root for this model.

2. Activity Persistence

shell activity is loaded when the project opens;
new activity is appended to that project's local history;
history is trimmed to the latest 500 entries.

3. Scope Rule

project-local shell history belongs to the project;
launcher-global concerns remain outside this storage path;
future Studio project configuration can live under the same .studio/ root.

Examples

Example: Why activity cannot stay application-global

If two projects have one shared persisted feed, the shell stops teaching the user what happened in the currently opened project. That destroys causality instead of preserving it.

Common Pitfalls and Anti-Patterns

Treating project activity as if it were launcher-global state.
Mixing unrelated projects into one persisted activity history.
Leaving project-local Studio files in ad hoc roots instead of .studio/.
Letting unbounded activity persistence grow without a hard cap.

References

Specs:
- ../specs/1. Studio Shell and Workspace Layout Specification.md
Related learn:
- ./mental-model-studio-shell.md

2.0 KiB Raw Blame History