You reach for "my project" expecting one thing, and meet a boundary the word never mentioned.
Signal
There are two features in the same product, both called projects, and they are not the same thing.
One lives in the cloud. It holds your conversations, carries shared instructions and files, and can be handed to other people. The other lives on your desktop. It is built around the tasks you run locally, it stores its files on your own disk, and — at least for now — it does not sync to the cloud or support the same sharing.
The only bridge between them is a one-time import. You can seed a local project from a cloud one, and the files and instructions copy across exactly once. After that, the two drift. Edit one and the other never learns.
None of this announces itself at the moment you need it. You think my project, singular, and reach for it as though there were one shelf your work sat on. Instead you meet a quiet seam the word smoothed over — a place where two different systems were both wearing the same label.
Pattern
Naming is not decoration. It is load-bearing, and it is famously hard: there is an old joke among engineers, usually attributed to Phil Karlton, that there are only two hard problems in computer science — cache invalidation and naming things.
A name is a signifier operating at the layer of language. Like the flat plate on a door that says push, a name makes a promise about what kind of thing you are dealing with and how it will behave. Software design even has a rule for keeping that promise: the principle of least astonishment — a system should behave the way its name and appearance lead a reasonable person to expect. Surprise is treated as a defect.
Two features sharing a name is a violation of that principle sitting in wait. And it rarely happens by carelessness. It happens because a word coined for one feature is the closest available word for a second, so the team reuses it. The reuse ships. The collision it creates is quietly transferred to the user, who now has to hold two meanings behind one label and discover, by stubbing a toe, which one they are standing in.
This is the affordance failure from an earlier note moved up one storey. There, the problem was a real door with no visible handle — a capability present but unsignalled. Here it is the mirror image: one signifier bolted onto two different doors, confidently pointing at both.
Implication
The confusion is only the symptom. The cause is a genuine, defensible fork in the architecture.
Underneath the shared word sits a real decision about where data should live. One path is the cloud: shared, synced, collaborative, reachable from any device. The other is local-first — the design philosophy Martin Kleppmann and his collaborators at Ink & Switch named in 2019, in which your data lives on your own machine, works offline, stays portable, and remains yours "in spite of the cloud." Local-first buys ownership, privacy, and durability, and it pays for them by giving up effortless sync and sharing. The two kinds of "project" simply took opposite roads at that fork.
The name flattened that decision into an apparent sameness. And so users make wrong bets against it: they expect a change in one to surface in the other, or try to share a thing that was never built to be shared, or trust that closing the laptop is safe because "it's in my project" — without knowing which project, on which side of the fork, they meant.
The repair is not only a better name, though a better name would help. It is legibility: letting the boundary show at the moment of choice, so a person can see they are picking between cloud-and-shared and local-and-private before they commit work to one. And it is anchoring the truth in the layer both systems actually share — the files on disk — so that the word matters less than the ground beneath it.
Posture
When a name is doing two jobs, name the boundary, not just the thing.
Refer to each "project" by what it guarantees — does it sync, can it be shared, where does it physically live — rather than by the label they have in common. Treat the shared word as a question, not an answer. And wherever you can, keep the source of truth in the substrate both sides point at, so that if the names ever misbehave, the work still has a floor. A structure that survives a confusing label is one whose meaning was never stored in the label to begin with.
Undersong
A name is a promise that two things are the same kind of thing. Stretch one word across two systems and the promise turns false — an affordance painted on a wall, a door that is only a picture of a door.
People do not read architecture. They read labels, and they walk toward whatever the label seems to offer. When the label has smoothed over a seam, that is exactly where they collide.
The repair is rarely just a rename. It is legibility — letting the boundary become visible — and it is putting the durable truth in the layer beneath the words, where a shared name can no longer do two jobs at once because the ground itself is doing the telling.
Drafted from a working session that ran into two different features sharing the word "projects" — one cloud-based and shareable, one desktop-local and private — and the confusion the shared name produced. Internal notes; no external source. Ideas referenced: the principle of least astonishment; the observation, attributed to Phil Karlton, that naming things is one of the hard problems in computing; Donald Norman on affordances and signifiers; and Martin Kleppmann et al., "Local-first software: you own your data, in spite of the cloud" (Ink & Switch, 2019).