Skip to content

[Feature Request] Project Layer Refactor: introduce Space above Project #1651

@4pmtong

Description

@4pmtong

Motivation

Eigent currently uses project_id as the main runtime boundary, but Project is also carrying folder binding, chat/session state, queued work, history grouping, generated files, and runtime metadata. This makes Project too overloaded.

We want to support a clearer model where one folder-backed context can contain multiple independent projects and runs. To do that, we need a new layer above Project.

Solution

Introduce Space as a new layer above Project.

A Space represents the folder-backed working context. It owns the selected source folder, shared file index, and future Space-level memory/instructions. A Project becomes an execution/session container inside a Space, with its own mode, chats, queued runs, history, and runtime state.

The target relationship is:

User
  -> Space
      source folder / shared context
      -> Project
          single-agent or workforce execution
          -> Run
              long-running task execution

The first implementation should focus on the model boundary, migration path, and compatibility with existing projects.

Alternatives

One alternative is to keep folder binding directly on Project. This is simpler short-term, but it makes it hard to support multiple projects inside the same folder-backed context.

Another alternative is to rename or expand the existing Workspace concept. This is risky because Workspace is already used in the codebase for lower-level runtime and UI concepts, such as physical working directory, workspace APIs, and active workspace state.

A third alternative is to only add more metadata to Project. That would avoid a larger migration, but it would keep the same overloaded model and make future concurrency, memory, and apply/discard flows harder to reason about.

Additional context

Related ideas from the design:

  • Space owns folder binding.
  • Project belongs to a Space.
  • Project mode should become immutable after the first run.
  • run_id should become the clearer execution identifier, while task_id remains a compatibility alias during migration.
  • Existing projects should migrate into a Legacy Space when needed.
  • Folder-bound legacy projects should preserve their existing root path.
  • Projects without a folder can become artifact-only projects.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions