Company OS — every project is a company

Every Wilow project is a company, and its repository is the company's source of truth: what it is, what it sells, which tools it uses, how work gets done, who decides, and why every change was made. Wilow adds this structure to a project the first time it opens it, without moving or deleting anything you already have. It works the same for a one-person website and a company with no software at all.

What Wilow adds to the repository

• company/ — the profile (what the company does, for whom, how it makes money), the offers, the brand.
• systems/ — one manifest per connected tool (hosting, database, email, payments, GitHub): purpose, environments, owner group, and references to its secrets. Never a secret value.
• processes/ — how work gets done, for people and for Wilow.
• decisions/ — one page per decision that shaped the company: context, decision, consequences.
• changes/ — one record per change (see below). The company's memory.
• standards/ and agents/AGENTS.md — the rules every agent follows, Wilow's or anyone else's.
• governance/ — who owns what, which mode the company is in, where changes are tested, how production is deployed.

Your existing files stay where they are. On the next run the agent fills in the profile and the manifests from what it knows about the project, and commits them.

Change records

Every change now leaves a record at changes/<date>-<name>/CONTEXT.md: the intent, what changed, the decisions taken, the open questions, and a short digest of the conversation that led there with at most three decisive quotes. Never the transcript: your conversations stay in the private vault on your computer. Records are listed newest-first in changes/INDEX.md, and a future session, or a colleague, can read why something is the way it is instead of asking around.

Owner groups

A group is a set of repository paths, not a list of people: governance/ownership.yaml says which group owns which folders, Wilow's Permissions card says who is in each group. Wilow createscompany-os, company, one group per connected system, and product when there is code; add your own from the Permissions card (a name and the paths it owns) or remove one you no longer need. An enterprise's Teams are something else: people you share workstreams with.

Ownership belongs to capability groups, never to people: product for the software, company for documents and processes, one group per connected system, and company-os for governance itself. A solo owner is a member of every group. Agents prefer the folders that exist (documents under company/ or docs/, code underapps/ or src/); when a change creates a new top-level folder, the same change lists it under its group in governance/ownership.yaml, or the merger holds the pull request until it does. Membership is managed in Wilow (the Control Panel's Permissions card); a generated CODEOWNERS file names the same people on GitHub.

Membership decides what a collaborator's Wilow may change. A collaborator writes the paths of the groups they belong to, plus the company domain (documents and processes) that everyone shares. When the owner shares a project, its existing editors are placed in every group except company-os, so nothing changes for them; editors who join later start with the company domain and the owner widens it from the Permissions card. A change that reaches outside the author's groups stays on their computer: the workstream says which group owns the files and what clears it, the owner sees "needs @product" on the workstream row, and the merger holds such a pull request regardless of who pushed it.

Governance modes

1. Bootstrap — you alone. Your own changes are reviewed by the merger and deploy right after the checks.
2. Collaborative — at least one editor. Collaborator pull requests need the owner's Wilow to approve.
3. Controlled — a group has two or more members. Changes to the domains the owner lists as review-required (company-os by default) wait for a person's approval: a member of that group who is not the author, or the owner, presses Approve in the workstream. When nobody but the author could approve, the merger proceeds on the owner's authority and says so.
4. Enterprise — more than five collaborators or an enterprise project. Teams, separation of duties, a hosted merger.

The mode follows the collaborator roster and the groups on its own; the workflow never changes with it, only who must approve and how production is gated. The Permissions card in the Control Panel shows the mode, the groups and their members, and what is waiting on a person, and is where the owner pins a stricter mode, never a looser one, and chooses which groups need a person's approval.

Workstreams

Once a project has the Company OS structure, every change happens in a workstream: one branch, one working copy on your computer, one chat, one Wilow session. The project's own chat becomes a concierge. It answers questions from the repository and the change records, and when you ask for a change it opens a workstream and continues there. You see it as a row under the project in the sidebar, with its state: active, review, held. The plus sign on a project row opens one by hand (it starts as NoName1 and takes its name from your first message, or from Rename in its menu); the cross on a workstream cancels it, closing its chat and pull request and deleting the branch. The owner may cancel any workstream of the project, a collaborator's included.

• Every push is a draft pull request, so the work is visible early and nothing is reviewed before you say so.
• Wilow CI. On a project with a GitHub repository, Wilow keeps a workflow that runs each app's own test, lint and build scripts on GitHub only when that app's files change in a pull request; changes to the company's documents never start it. The merger waits for the run and holds a pull request whose run failed, with the link. It needs no secrets on GitHub. A project whose code lives at the repository root counts as one app; Playwright browsers are installed on the runner when the app uses Playwright.
• Merger failover. On an enterprise project the merge pass runs on the host's Wilow. When that computer has been offline for ten minutes, the Wilow of an enterprise owner or admin who is online stands in: the same gate, the same review, the same receipts, one reviewer at a time. Production deploy waits for the host's Wilow, which deploys what was merged in its absence as soon as it is back, unless the owner has shared the deploy token: the vault holds it as deploy/vercel/token, readable by the owner alone until a group is ticked in the Secrets card, and a standby whose person is in that group deploys what it merges. Personal projects merge only on the owner's computer.
• Sparse worktrees. A collaborator's workstream checks out what their groups own plus the company's documents and the root files; the folders of other groups stay out of that worktree (the chat lists them). The agent reads them from main when it needs context, and the owner's own workstreams stay complete.
• Ready for review marks the pull request ready, checks the change record, and calls the merger at once, even when you work alone. While the merger waits for something — a linked workstream, an approval, the preview to be tried — the workstream reads Waiting in amber, with the reason on hover and in its chat; Held means the merger sent it back with a fix to make. Wilow's own progress lines in a workstream chat are shown as small receipts, not as messages.
• A hold comes back into the workstream with the reason and a red badge on the project's History; a fix pushed there sends it back to the merger.
• A merge archives the workstream: the working copy and branch are removed, the chat locks and brings you back to the project's chat, and one line stays in History next to the change record. Further changes start a new workstream.
• When one workstream merges, the others follow the new main right away: each open workstream on that computer is rebased and pushed, and a workstream already in review goes back to the merger at once, so the next pull request merges in one pass. When that rebase conflicts on an idle workstream, its own Wilow resolves the conflict and says so in the chat.
• Collaborators with the editor role open their own workstreams from their copy of the project. Their Wilow runs the work; the chat lives with the project so the owner and every member can read it, and only its holder writes in it. The owner's Wilow reviews and merges it like any other.
• A change that touches files outside the holder's groups stays on their computer, and the workstream shows "needs @group". The owner clears it either by adding them to the group in the Permissions card or, from the workstream's header, by allowing just that change for that workstream.
• ▶ Preview in the workstream header runs the app from that workstream's working copy on the holder's computer, on its own port, and the Preview tab shows it there. It stops after an hour, or with the same button, or when the workstream closes. Its receipts land in the project's History.
• Share preview gives the project a private link to that running preview — a Cloudflare quick tunnel to a gate that only lets in people signed in to Wilow who are on the project. Colleagues and phones open it with Open preview; the first time, the link takes you to Wilow's sign-in (the screen says which preview it is for) and brings you straight back once you are signed in — with Google or email, on a phone or a computer. Someone who is not on the project sees a plain "you don't have access" page instead. The link ends with the preview. Nothing is public and the dev server itself never leaves the holder's computer.
• Share (the workstream's ⋯ menu; its holder or the project's owner) shows a workstream to a collaborator of the project or, on an enterprise project, to an enterprise member. Sharing is visibility only: they read its chat and preview while it is open, and nobody but the holder edits it. It appears for them under the project, or under Shared with you when they are not on the project; the share ends with the workstream. Discuss in team chat posts the workstream into the project's team chat with an Open button; right-click any message, yours or Wilow's, to post that message there as a quote, and Open brings the reader back to it.
• Link ties open workstreams of a project into a group: their chats and pull requests say so, a strip under each header opens the others, they sit together in the sidebar joined by a line, and Wilow's merger takes the group together or not at all — none merges until every member is ready for review with its preview approved and its checks clear, and their change records point at each other. Linking a workstream that already has a group joins the two groups; tapping a linked one in the same dialog takes it out of the group.
• Hand over (the ⋯ menu) passes a workstream to a colleague: the holder's Wilow commits and pushes what it has, the owner's Wilow moves the lease, and the new holder's Wilow takes over the same branch, pull request and chat, briefed on what was done. The list offers the project's editors and its owner. The owner can Reassign any workstream the same way, for instance when its holder is away; anything that holder never pushed stays on their computer, and their Wilow says how many changes stayed behind. The header reads "Handing over…" until the lease has moved.
• Teams (Settings → Enterprises → Teams; the enterprise's owner or an admin) are named groups of an enterprise's members. Share a workstream with a team and everyone in it reads it while it is open; on a project with more than five collaborators, the sidebar shows your own workstreams and your teams', and the board's "shared with me" filter counts them too. Each team is mirrored as a GitHub team of the same name in the enterprise's organisation, with the same members and read access to every enterprise repository; a change here reaches GitHub within seconds, removing a team here removes the one Wilow made on GitHub, and teams made by hand on GitHub are never touched. Personal projects are unchanged.
• The Control Panel's Workstreams card lists every open workstream of the project — holder, state, pull request, preview — with filters by mine / shared with me, state and person, and an Open button into each chat. A project with more than five collaborators shows only your workstreams and the ones shared with you under its sidebar row; the board keeps the rest.
• Secrets never live in Git. The manifests under systems/ and apps/ hold references; in the Permissions card's Secrets the owner sets each value once, or adds a reference by hand with Add a secret… (dev/… for the preview, prod/… for GitHub Actions). Vault values are sealed for the groups the owner ticks: each owner group has its own key, held only by the owner's Wilow and the Wilows of that group's editors, so a collaborator outside those groups cannot decrypt the value, not merely not see it; when someone leaves a group its key rotates. Values reach a collaborator's preview as environment variables named from the reference; production values go to the repository's GitHub Actions secrets and are never read back.
• Preview before merge is one switch per project, on the Workstreams card of the Control Panel. Only the project's owner changes it; every workstream of the project, the owner's and the collaborators', follows it. It is on for every new project and takes effect once the project deploys previews (a hosting link). An enterprise can require it on every one of its projects (Enterprise settings → Policies), and then the switch is locked on.
• Peer preview. While the holder's preview runs, a colleague on their desktop opens it with Open preview in the workstream's header: their own Wilow connects to the holder's Wilow directly, end to end encrypted, and the Preview tab shows the app. Nothing is published and no third party is involved. It ends when the holder stops the preview, after an hour, or with Close preview. On a phone or in a plain browser the same button asks your Wilow on your computer to open the preview and hand you a private link to it (you sign in with Wilow the first time); your computer must be on.
• Once a workstream is in review on a project hosted on Vercel, the owner's Wilow deploys the branch as a non-production preview and puts a Preview link in the workstream's ⋯ menu, next to the pull request, for everyone on the project. Every push while in review updates it (the chat says when a new one is being prepared). The merger waits until the holder or the owner has tried it and pressed Approve preview (or Continue editing to reopen the chat). A push that changes the work asks again; a commit Wilow made on its own, such as a rebase, a conflict resolution or a change-record fix, keeps the approval when the pull request still touches the same application files, and the chat says so. Production still deploys only on merge. If the preview cannot be deployed at all — most often because the Vercel CLI is missing on the owner's computer — Wilow says so in the workstream, reviews the change on the code alone rather than blocking it forever, and never offers an earlier preview as if it were this change.

The optimiser

A company drifts: a new folder nobody owns, a group nobody is in, a merged change without its record, a vision that stopped moving, a secret referenced but never set. On a Company OS project you own, the ⋯ menu has an Optimiser toggle (separate from Autopilot): while it is on, a pass every four hours and after every merge checks exactly those things, without spending a token. "Run now" beside it runs a pass right away. The optimiser is the owner's: it runs on the owner's computer and speaks in the owner's chat, so a collaborator's copy never shows the toggle; collaborators meet its housekeeping workstreams under the project like any other, held by "Wilow".

• Housekeeping it can do alone arrives as one proposal, "Wilow can tidy N things"; one tap opens a workstream whose first message lists exactly what to tidy, and it goes through the same pull request and merger gate as any change. Wilow never opens a workstream nobody asked for.
• What needs you arrives once in the Project chat as "Wilow noticed: …" with Open a workstream and Dismiss. Once you answer, the line shows what happened: "Dismissed", or an Open button into the workstream. Dismissed stays dismissed.
• The Permissions card shows the optimiser's state and how many proposals wait for you.

What comes next

Peer previews of a branch straight from a colleague's computer, without anything public, follow in a later release. The design is in the open: every decision and its reason is recorded in the daemon repository's specs.