From Console to Workspace: Naming a Product Surface

We recently changed a word at the centre of FireUX: Console became Workspace.

This was not a cosmetic rename. The old word described a technical control panel. The new word describes the product surface where a person selects a real Entity and works with its identity, team and domain capabilities.

The architectural lesson survived the rename: a Workspace composes those capabilities, but it does not own the Entities or operations displayed inside it.

Product names shape architecture

Names influence more than navigation labels. They affect folder boundaries, route families, component names, permissions and the explanations developers give to each other.

“Console” encouraged us to think about a generic technical container. Features could be added because they looked like admin controls. “Workspace” makes the product question more concrete: whose work is this, which Entity is selected, and which capabilities are authorized for that context?

That change exposed stale assumptions. A Workspace is not a database record embedded on every Entity. It is not a universal manager that absorbs domain logic. It is an authorized surface and selected-Entity runtime.

Composition is not ownership

Consider a Kitchen Workspace containing Overview, Identity, Team and Finance. They share navigation and depend on the same selected Kitchen, but they do not perform the same job.

Identity describes the Kitchen. Team controls who can act for it. Finance presents authoritative financial facts. An operation such as managing Recipes owns its own records and lifecycle.

Calling all of these things operations would make the navigation easier to generalize temporarily, but it would make the underlying product harder to explain and change. Overview, Identity and Team are first-class peers. Operations is the group for genuine domain work inside the selected Workspace.

The Workspace owns surface concerns: selecting an authorized target, composing navigation, presenting shared outcomes and keeping the working context stable while routes change. Each Entity continues to own its models, permissions, commands, adapters and product language.

One surface, named Entity families

Different Entity families can use the same Workspace spine without pretending their products are identical.

A Project Workspace and Kitchen Workspace share the route rhythm, selection contract, Overview, Identity and Team. Their operational domains are materially different. Project coordinates Apps and an Ecosystem. Kitchen works with Dishes, Menus, Orders, Recipes, Stations and other Kitchen-owned capabilities.

Those differences are not exceptions to hide behind a large configuration object. They are the reason named Entity adapters remain useful. Shared Workspace mechanics live in the common spine; Entity-specific components and composables live beneath their Entity owner.

This follows the same direction described in our article about extending the Nuxt spine: framework entrypoint, Entity-owned implementation, shared package spine, then framework primitives.

Thin routes preserve the boundary

The canonical routes now live under /workspace. A route page owns the Nuxt boundary and visible page composition. It delegates data, permissions, states and mutations to named domain components and composables.

Keeping routes thin prevents Workspace from becoming a second owner of every capability. It also makes the architecture easier for people and AI coding agents to navigate: a Workspace page shows how the surface is assembled, while the Entity tree shows where the real behaviour belongs.

A practical test

When adding something to a Workspace, ask:

1. Which Entity is selected?
2. What record or capability does the person act on?
3. Which domain defines its authority and lifecycle?
4. What does Workspace need purely to select, present or navigate it?
5. Is the feature genuinely an Operation, or is it Identity, Team, Overview or a child Tool?

If removing the Workspace surface would not remove the underlying product meaning, the Workspace probably does not own that capability.

What we changed at FireUX

FireUX now uses Workspace as its product vocabulary and /workspace/** as the canonical route family. Shared Workspace shells, navigation, selection and outcome primitives remain in the root technical spine. Kitchen, Project, Supplier and other Entity-specific Workspace adapters remain beneath their Entity roots.

We also use two materially different proving siblings—Kitchen and Project—to test which Workspace contracts are genuinely shared. This avoids building a universal Workspace framework from one domain's needs.

The existing article URL still contains the earlier Console wording. Keeping that URL stable preserves references from previous tasks and articles; the updated title and content record the architectural correction instead of hiding it.

Future tasks may use this article as orientation and shared vocabulary, but the article is not implementation authority. They must still verify current source, repository guards and living context before changing Workspace code.

The broader lesson is that a better product name can reveal a better ownership boundary. Rename the concept only when its job is clear—and then let routes, source and documentation tell the same story.