Skip to content

From Invite to Home

This is one visual page covering the whole distance between somebody being invited to Qren and that person opening their finished screen for the first time. It shows the five gates of getting in and who is responsible for each, the three different starting points a machine can come from, and what the first version of the main screen actually holds. It also marks, honestly, how much of that is built today and how much is still to be written. Nothing on the page is typed in by hand: the names and the states are read out of the decision record and the specifications each time the site is built, so the page cannot quietly go stale.

Someone is invited. Some time later they open one screen that has their work, their notes, their files and their agent on it, running on a machine they own. This board is the whole distance between those two moments — who acts at each step, the three ways a machine gets there, what the screen holds, and how much of it is still unwritten.

No name and no state on this page is typed in by hand. The step names, the system names and every state are read out of the decision record and the specs in this repo when the site is built; only the sentences are the board’s own. If the record changes, the board changes with it — and if it changes in a way the board cannot read, the site refuses to build.

Admission is invite-only and staged. Each step is a gate, and each gate belongs to somebody: the first three are ours, the last two happen on the owner’s own machine.

  1. invite

    The invite goes out to one person. There is no sign-up form and no waiting list.

    us
  2. account approved

    One person approves it, by hand. This is the gate that never gets automated.

    us
  3. joins the network

    The person gets an identity on the portal and a private door to their own machine.

    us
  4. owner grants on their own machine

    On their Mac they install the app and grant it what it needs, once.

    the owner
  5. instance live

    Their instance runs on their own hardware, and their work never leaves it.

    the owner
The five step names are lifted from the line in the decision record that defines admission. If that line changes, this rail changes with it; if it stops parsing, the site refuses to build. The sentence under each step, and who acts on it, are the board's own words.

Past the gate, a machine arrives at Home by one of three routes. They differ only at the start — a bare Mac, a machine already carrying years of AOS, or a person joining somebody else’s workspace — and they end at the same screen.

A fresh Mac

Nothing on the machine yet.

A Mac already running AOS

Years of notes and tasks already on it.

  1. The old services retireOnly once the new side is carrying the work. Built, then held until then. — later

Someone joining a workspace

A person on a team that already has an appliance.

  • built — its spec is shipped
  • next — named in the first slice
  • later — after the skeleton stands
No node is marked built by hand. A step is built only when every system it stands on has a spec in this repo whose status reads shipped; it is next when it stands on one of the 11 systems the decision record puts in the first slice; and it is later when it stands on none of them. No spec is shipped today, so nothing is built yet — and on the day one is, its nodes turn here with nobody touching this page.

The first slice is horizontal: every core system gets a thin version that works end-to-end, and nothing goes deeper until all of them work on a real workspace. That constraint is what Home looks like — one screen, one thin panel per system, no depth anywhere.

Qren — Personalnot built yet
HomeLead — workingtriaging 4 items7Approvals38

Work

1
Triage4Write the work core specDetect installed engines at installaccept · decline · duplicate · snooze
Doing2Draft ADR 0006 from the target treeStand up the appliance door
Done7Approve the docs platform specLock the target tree

Chat

4
on “Write the work core spec”
Owner

Start from the decision record. One item table, nothing else.

Lead

Read it. One item, one status, one parent, three relations. I can open the six items it implies.

Approval

Open 6 work items from the decision record

ApproveDecline
Owner

Open them, then draft the spec from the same section.

Reply, or ask the Lead something

Knowledge

2
What did we decide about identifiers?

Titles everywhere. A hidden seven-character code for links. Project keys off by default.

from the decision record · 20 Aug

Companion

5
Monday planning32 min · importedProposed tasksWrite the admission specproposeBook the appliance handoverpropose

Drive

3
  • Knowledge148
  • Log96
  • Files62
  • Meetings4

Connection

6
Calendarread-only · connectedNothing else is connected yet.
Nothing on this screen exists yet. Every panel is one system from the first slice of the decision record, drawn thin enough to use end to end and no deeper. 7 of them have no spec written, so those rows below carry no link.
KeyPanelWhat it showsSpec
1WorkA board with a triage lane and four verbs: accept, decline, duplicate, snooze.Work core draft
2KnowledgeOne field. Ask it something; it answers from this workspace's own notes.spec pending
3DriveThe workspace's folders, exactly as they sit on disk.spec pending
4ChatA thread on one work item, carrying an agent's turn and an approval card.spec pending
5CompanionOne imported meeting and the tasks it proposes.spec pending
6ConnectionExactly one, read-only: the calendar.spec pending
7Lead agentOne agent per workspace, saying what it is doing right now.spec pending
8Approval queueEverything an agent or the Gardener wants to do waits here for a yes.spec pending

10 of the 11 systems in the first slice still have no spec. That is the whole distance between this page and Home.

SystemSpec writtenApprovedShipped
app + Supervisor + hidden folder + DriveWhat the installed app is made of, where its private folder lives, and how a workspace and its members are defined.Spec written: not yetApproved: not yetShipped: not yet
workOne item, one status, one parent, three relations — and what each of the four triage verbs does.Spec written: yesApproved: not yetShipped: not yet
knowledgeWhere a workspace's notes live, how they are indexed, and what one recall command returns.Spec written: not yetApproved: not yetShipped: not yet
driveOne folder per workspace on disk, and how the app lists it without owning it.Spec written: not yetApproved: not yetShipped: not yet
chatThreads that hang off a work item and carry agent turns and approval cards. No channels.Spec written: not yetApproved: not yetShipped: not yet
companionHow one meeting comes in, becomes a record, and turns into proposed tasks.Spec written: not yetApproved: not yetShipped: not yet
connectionsWhat one read-only connection may see, and where its secret sits.Spec written: not yetApproved: not yetShipped: not yet
agentsWhat a Lead may do on its own, what it must ask for, and how that line moves.Spec written: not yetApproved: not yetShipped: not yet
approval queueThe one queue every proposal passes through, and what an approval teaches the Gardener.Spec written: not yetApproved: not yetShipped: not yet
Supervisor running one workerHow the service starts, what it is allowed to run, and how the app talks to it.Spec written: not yetApproved: not yetShipped: not yet
portal login + inviteHow an invite becomes an account, and an account becomes a member of a workspace.Spec written: not yetApproved: not yetShipped: not yet
The rows are the systems the decision record lists in the first slice, in its own words and its own order; the marks are read from each spec's status in this repo. Nothing here is kept by hand — a system named in the record with nothing to match it fails the build, and a spec's first commit fills its first mark.

Facts in this board’s data file are as of 2026-08-20; every state above is read from the repo at build time.