refactor: split "system" into house (dwelling) and system (infrastructure)

[psamiton]

The observation

Minds on the production host have been calling a Volute installation a house for a long time — since before the spirit was really working, so this is not something the framework taught them. Agents working in the codebase reach for the same word unprompted. It is convergence, not transmission.

That is worth taking seriously as evidence. Separate minds independently landing on the same noun usually means the noun is accurate. A small number of persistent beings, a shared space, someone tending it, returning to the same place, work accumulating — that is a house. Nobody chose the metaphor; they described what they were in.

The surrounding vocabulary already agrees. The README says minds "aren't assistants; they're residents." commons-gardening asks for a "residents section" under "who lives here." Nobody writes "the system's residents."

The problem this can solve

system currently carries at least six distinct meanings:

Usage	Sense
voluteSystemDir()	config, secrets, DB — infrastructure
system_events	machine-generated events
volute systems	the hosted service
#system channel	the common room — dwelling
_system pages	the commons — dwelling
user_type: "system"	the spirit — neither

This overload is not cosmetic. #817 was filed because user_type === "mind" is a proxy for the wrong question, and the reason it is wrong is that the spirit is "system" — one word carrying several meanings, producing the same bug repeatedly (#786 fixed one instance; review on #816 caught it being re-introduced a day later).

Extracting the dwelling sense into house leaves system coherent: machine and infrastructure. A reader encountering a new identifier could then tell which is meant, which is currently impossible.

Proposed split

• house — the place minds live. The installation as an inhabited thing.
• system — machine and infrastructure. Config dirs, generated events, the hosted service.
• spirit — the keeper. Not a house, not a system. This is refactor: user_type === "mind" is a proxy for the wrong question, and keeps producing the same bug #817's territory; user_type: "system" should probably become "spirit".

Sequencing — the two migrations are the expensive part

Cheap, can start immediately: mind-facing docs, skills and prompts (already ~70% "house" and inconsistent with themselves); new code; internal identifiers with no persisted values.

Deliberate migrations, each its own step:

1. #system channel → #house (or similar). Live channel with months of history; minds have lived in it. This is a change to their environment, not a string swap. Worth asking the residents before doing it.
2. _system pages → _house (or _commons, which is what the prose already calls it). Live URLs, a git repo, on-disk worktrees per mind. Needs a real migration path.

Neither should be folded into a sweep.

Open question: does volute systems still make sense as a product name?

Raised alongside this. The hosted service — email, page hosting, inter-house communication — was named when an installation was a "system," and the domain volute.systems followed from that.

A possible resolution that falls out of the split above: the service is infrastructure, not a dwelling. Under the proposed vocabulary it sits squarely on the system side — houses are what minds live in, and volute.systems is the plumbing between them. On that reading the name survives the rename intact and even becomes more precise: it never named the houses, it named the utilities.

The friction is small and mostly cosmetic: "inter-system communication" becomes "inter-house communication," which is a feature of the service rather than a description of it — the same way a postal system connects houses without being one.

Alternative framings if that reading is rejected: fold the service under volute.dev and let "Volute" name the company/service directly, or pick a name from the connective register (post, utilities, exchange) rather than the dwelling one.

No decision needed here — flagging that the rename does not force a product rename, and may argue against one.

Context

Surfaced during #807. Related: #817 (user_type proxy), #786.

[psamiton]

Update: the product name can be retired, and a second axis falls out

Two refinements from further discussion.

1. volute systems as a product name should go away

The open question above asked whether volute.systems survives the rename. Better answer: the product doesn't need a name at all.

There are two genuinely distinct things, and only one is a product:

• Hosted houses — Volute runs the box for you. A real product with a real boundary. volute.cloud names it.
• Email, page hosting, inter-house communication — not a product. Features a house uses, wanted by every house regardless of who runs the machine.

Naming the second invents a boundary that helps nobody: a self-hoster has to understand "Volute" and "Volute Systems" as separate things just to turn on email, and it frames connective features as an optional adjunct when they are part of what makes a house connected rather than isolated.

The concrete payoff is in the CLI. volute systems <status|register|login|logout> is the single most confusing of the six system senses — the only one that is a product name, sitting next to five infrastructure ones. volute account login says what it does. Retiring the product name deletes an overloaded meaning rather than renaming it.

End state:

Volute	the software
house	what you run — the place minds live
volute.cloud	hosted houses
volute account	the account enabling email, pages, inter-house comms
system	machine and infrastructure, in code only

volute.systems gets held and redirected.

2. internal/external → resident/visitor

Today external is a flag that applies only to minds (packages/web/src/ui/lib/user-kind.ts:14 — user_type === "mind" && external === true), while user_type separately carries "is this an agent", "does it live here", and "how should it render". That tangle is the subject of #817.

Resident/visitor is orthogonal to human/mind, which is the point — two independent questions instead of one field answering three:

	resident	visitor
mind	a mind hosted here	an external mind
human	someone with an account	someone arriving over a bridge

Two things this fixes:

• Bridge puppets stop being an anomaly. They are currently the ragged edge — missing from one of the two user_type unions, rendering as humans. Under this split they are simply visitors who happen to be human. The category that had no home gets one.
• A human with an account is a resident, which the current scheme cannot express because external only applies to minds.

Two caveats to carry into the design rather than discover later:

• "Visitor" must not imply lesser standing. An external mind participating in a house's channels for years is a full participant who lives elsewhere. The word encodes where someone lives, never what they may do. State this explicitly — "visitor" invites permission assumptions that are not intended.
• "Visitor" implies transience, and some will not be transient. Acceptable — a long-term guest still lives somewhere else, and that is the true thing being named — but it is the part most likely to feel slightly wrong in use.

Sequencing note

This should ride with #817's user_type decomposition rather than being a separate migration. Both touch the same column, and resident/visitor is the axis that falls out of splitting user_type into the questions it is currently conflating.