WWorkomatorOpen workspace
← Guides

The boundary

Workspace and project space

Know where a thought belongs, so work in progress stays private and the shared project record stays useful to everyone building it.

How information earns a shared home Private until contributed

Workspace

CaptureThoughts, notes, context
Decide / BuilderShape the next move

Project space

RoadmapOutcomes
FeaturesValue
SpecsBehavior
Memory + wikiBrief, decisions, constraints, references
Work starts in your workspace. Publish only the decisions and context that need to guide the project.

Workomator has two places for information, because not every useful thought is ready to become shared direction. Your workspace is where you do your work — thinking in progress, private to you. Project space is the shared record — the context a team needs to act together.

Keeping those roles separate protects both. You can capture ideas without performing them for a group, and the project stays a clear record the whole team can follow.

Workspace: where your work happens

Your workspace is the private space where work starts. Capture a tension, a question, an observation, or a possible next move while it is still forming. Your Idea field and Build queue stay private to you.

Use it to:

  • capture the thought before it is polished or classified;
  • explore whether it is a task, a decision, or a potential specification;
  • refine the intended outcome and identify what is still unclear; and
  • take on work without making every early move visible to the team.

The important rule is simple: private thoughts deserve care. The source context stays attached as a thought moves forward, so you do not have to reconstruct why it mattered later.

Project space: the shared product record

Project space holds what the team needs to act together: the decisions, constraints, and plans that should outlast any one person’s task.

It includes:

  • Roadmap — the sequence of meaningful outcomes and their current state;
  • Features — the product capabilities under consideration, their horizon, intended outcome, and success signal;
  • Specs — build-ready definitions of behavior, scope, review state, and published revisions; and
  • Project memory and wiki — the brief, product language, decisions, constraints, and references that give the plan its meaning.

Project memory is the lasting context behind the plan. Features and specs should use that context without copying it into every record.

When should work move into the project?

Move information into the project when it needs to become a reliable reference for more than one person. A useful test is: would someone else need this to make the same decision or do the work well?

If the answer is yes, make it part of the project record. That might mean adding a constraint to memory, recording a decision in the wiki, placing an outcome on the roadmap, or creating a feature or spec for shared review.

If the thought is still exploratory, uncertain, or only affects your own next move, keep it in your workspace until it earns that role.

The result: shared direction without shared noise

The boundary lets each person work freely while the project stays clear. Work in progress can be messy and provisional. The shared record stays deliberate and ready for collaboration.

That is how Workomator keeps the reasoning close to the work without turning every private note into a team obligation.

← Back to Guides