People

Renee holds eleven of thirteen. She drafts change orders, settles decisions, writes quotes, invites people and reports contract figures. The two she does not hold are both money-with-consequences: voiding a signed amendment, and changing what somebody else can do.

This table drew ten rows and said thirteen, and DB_DIAGRAM.md §8 item 10 recorded three as counted-and-not-named. The arithmetic was off twice: the first row is two capabilities, not one, so ten rows carried eleven — and the genuinely absent pair was two. They are here now: reading and answering the homeowner, which is every thread, ask and digest on the page, and putting a sub on a job. Both are on by default, which keeps frame 5's eleven of thirteen are never in question true.

Not for Dave either. Allowances are the homeowner's, he reports and she confirms, and nothing he writes is money she owes until she says so. A builder-side set the allowance button would quietly move the whole product's center of gravity.

Renee sees this page, sees both controls she cannot use, and sees why. There is no admin view and no owner view — one app, and the two rows above are the whole of the difference.

A homeowner and a tile setter, in one list, in one shape. Filing them separately is where sub starts turning into a kind of user, and the moment it does, somebody builds a sub login and a sub dashboard and the account-less tier grows a second class in it.

Sam does, Ben does not, and the rows are identical. An account is a badge on a person and it is not this product's business to display it — a year later the record must not be able to tell the two paths apart and must not care.

Add a contact and add somebody are different verbs on different lists. A contact is somebody you deal with; a seat is somebody who holds part of your subscription. Merging them is how a builder accidentally gives his tile setter a login.

Said once, on the builder's own screen, so he does not go looking for a login to send. It is a fact about how to reach somebody — the same register as the phone number above it — rather than a status on a person, and it never appears on a row, a chip or a name anywhere else.

Not a message thread. Every row is half of a send, including the one that could not be routed, and the unrouted reply is as visible here as it is in Send — because a reply path that hides its failures is a reply path that lies.

The same contact can cover different work on two projects. Rooms and Systems are assigned here, on the project, and stay editable; they are not inferred from workstreams or stored as a category on Luis.

Frame 2 says subs, vendors, homeowners, inspectors and lenders are one list and one shape. A type dropdown here would undo that in the one place it is easiest to add and hardest to remove — the moment a contact has a category, somebody filters by it, and the subs tab this page refuses arrives by the back door.

There is a trade column on six tables today and no shared vocabulary behind any of them. A picker would have to invent that vocabulary and then be wrong for somebody — tile setter, tile and flooring are the same person at three companies. Free text is the honest shape until a real list exists.

The number. Everything the product does with a contact is a send and a reply, so a contact with no number is a note about a person rather than a person the app can reach. The other three are conveniences and the screen does not pretend otherwise.

Q6 ruled that People are typed by hand rather than inferred. Rooms handle a cabinet installer on two spaces; Systems handle an electrician across the whole house. A contact with both matches work only where both axes meet.

The alternative was Owner and Member, and it is wrong for a company of two: a tier makes somebody a lesser kind of person, and the difference here is two specific acts with money behind them. Naming the acts is also the only version that stays honest when a third capability becomes contentious — a tier absorbs it silently, a switch has to be added and argued.

Unwinding money both sides have agreed to is what the switch does; void_change_order is what it is called. The field rule in forms.css is explicit that a hint explains the ask and never the format, and a capability's hint is the same problem — the reader is deciding about a consequence, not a permission name.

Which is not a contradiction of mockup 14. Two people who live in the same house are peers by definition; two people who work at the same company are not, and one of them signs the contracts. The homeowner invite has no switches at all, and neither screen borrows the other's shape.

The builder's own seat on a job is the house's owner seat too, and a colleague can be given one. Nothing about a seat says client, and every rule that guessed from seat history was wrong for somebody: a client who once worked for the builder, or staff who only ever held owner seats. Q298 ruled that the builder says so here, once, per invite.

Drawn with the first chosen so both states show. On arrival neither is, and Send invite stays off until one is: a default would be the guess again, made by the screen instead of the server. An invite sent without an answer — one from before this screen existed — never files the house under anyone.

What the answer drives is which household the house joins (HOMEOWNER_MEMORY_DESIGN §3), and that word is nowhere on a builder's screen. The house is Nora's is what a builder can answer without knowing it; the seat and what it can do are identical either way. The captions promise nothing about what the product learns: that is the homeowner's disclosure (AN6), not the builder's to describe.

The answer does nothing until Nora accepts, so until then it is only words on the invite and the builder can change them. Drawn mid-correction: the invite says works with you, Dave has tapped is the client, and Save answer is on because the two differ. It is off when they match. Nora is not emailed again; she never sees the answer.

Accepting is when the house is filed (Q298), and this screen stops existing for her: she is a seat, not an invite. A house filed on a wrong answer is corrected by removing that seat and inviting again, which asks frame 6's question afresh. Moving a house out of a household is AN5's to design, not this screen's.

Marco's company invite on frame 1 opens this same screen without the question, because a builder seat has no answer to give. Canceling ends the invite for good: the link refuses, the row leaves the list, and inviting the same address again is a new invite with its own answer. Owner invites never expire, so without this a wrong one would sit there until somebody accepted it.

Changing the answer or canceling asks what sending that invite asked (Q122): an owner invite needs what the house's owner seat holds, and a company invite that chose what somebody can do needs Change what somebody can do. Renee can cancel an invite she could have sent, and no other.