A project, one object, everywhere.
You type a client's name into the gallery, then again into the quote, then again into the post. The intention is that a project stops being a folder copied from one app to the next: the gallery, the campaign and the invoice would all point at the same one. The organisation-scoped kernel now defines that boundary; the surface lists labeled fixtures so that isolation can be inspected while the entity is being built.
The surface behind the button is organisation-scoped: it lists labeled kernel fixtures for that tenant and resolves covers through the asset resolver. That is demonstration data, not a project database.
What this product does
Hold a project in one object
The project is meant to carry its name, its client and its state in one place, rather than exist as three copies in three apps.
Be the thing everything attaches to
Other modules would point at the project by id, never copy its data into their own store, and never change it on its behalf.
Give a readable state
Knowing where a job stands without opening four tools: that's what this surface will have to make possible, the day the entity exists.
In detail
A kernel object, not a feature of this hub
Contact, Client and Project are planned at the ecosystem kernel level, precisely because every module references them. So this hub won't own them, it will show them. This page isn't the promise of a project management app. It's the place held for a shared entity.
Referenced by id
The prefix is settled in the architecture, the entity isn't. That's the normal order: you name before you build.
No table, no code
There's no product database or write service behind this surface yet. The kernel contract exists; the rows you can inspect are labeled fixtures so tenancy can be checked.
After the foundations, not before
The project repository is connected to the kernel foundations: tenancy is checked before projects are listed, and cover assets resolve in the same organisation context. The product surface stays empty until real project data exists.
Who it is for
- Following a photo job
- The project would be the thread between the session, the delivered gallery and the documents that go with it.
- Grouping by client
- Finding what has been done for a given client would mean reading the projects attached to their record, rather than digging through each app.
- Linking two modules
- A campaign that came out of a gallery could point at the same project it does, without either one copying the data of the other.
See the shell
The surface exists to hold the place and show the empty state. There's nothing to enter into it today.