Local and Cloud boards

Every board is authoritative in exactly one place, and that place is what tells the two kinds apart.

A Local board

The cards, the memory files, the releases and the board's configuration are Markdown under docs/kanban/ in your own repository. Git carries them, you read them, your coding agent reads them, and no board content leaves the machine.

The one thing a Local board does send is anonymous usage reporting, which is on by default: which features are used and which of them fail, and how many cards a board created, completed and rejected — counts and event names, never a card, a project name or a file path. The app discloses it in a step you answer before your first board opens, and you can turn it off there, in Configuration → General, or with akb telemetry off. Every event and field is listed in the Privacy Policy.

This is what a new install starts on. Create Local board on the launcher picks a project folder and puts a board in it; Open Local board picks a folder that already has one. Both are the same folder picker under different intent, and a mismatch falls through to what the folder actually holds — Open on a folder with no board offers to make one, and Create on a folder that has one opens it. Nothing overwrites a board.

A Cloud board

The cards, the memory, the releases and the whole history live in a workspace we host, so the board opens on every machine you sign in from. It is an invite-only preview in this release: what Cloud is, and the Privacy Policy and Terms of Service.

A Cloud board is still a folder on this machine. The checkout carries two things:

• .ai4kanban.json at the repository root, naming the workspace. It is committed, so every clone of the repository opens the same Cloud board. It carries no secret — a workspace id means nothing without the sign-in your machine holds.
• A git-ignored copy in docs/kanban/. The board's own rules run over that copy, and it is rewritten from the workspace on every read. It is a copy, never the record.

Cloud decides where the board is authoritative. It does not decide whether there is a project folder — the agent still runs here, over your repository, exactly as it does on a Local board.

Going to Cloud

Take Create Cloud board or Open Cloud board on the launcher. It walks through the GitHub sign-in, the workspace, the folder on this machine, and — where the folder already holds a board — importing its cards into the workspace.

Once the workspace is yours, the repository has three changes in it: the board files stop being tracked, .ai4kanban.json is added, and docs/kanban/ joins the root .gitignore. The app offers those as one commit, staged by path, so nothing else in your working tree goes with it. Decline it and the checkout still works — git status is simply full of the change, and the offer comes back under Configuration → Workspace until you take it.

Nothing is lost either way: the cards are in git history whichever way you answer, and what the offer decides is whether git records the move.

A folder with no git repository takes the same path. The workspace is made, the board opens and the pointer is written; the offer says there is nothing to commit to yet.

Members and roles

A workspace holds the people an owner has added to it, and answers nobody else. There are two roles and no third:

• Owner — runs the workspace's name, its members and their roles, its execution nodes, and its deletion.
• Member — every ordinary board operation: reading it, writing a card, running its work, registering their own machine.

Everyone in a workspace reads the whole board and the whole record of who changed what. There are no per-card permissions.

An owner adds somebody by GitHub handle, and only somebody we have already admitted to the preview. Adding does not admit: a handle we have not let in is refused, and the workspace keeps nothing for it. That person presses Request an invite in the app like anyone else, and the owner adds them once we approve it.

A workspace always keeps an owner. The role change or removal that would leave none is refused. Closing an account never deletes a workspace either — transfer it to another owner, or delete it, first.

Removing somebody stops their next write, not the screen they have open. Nothing pushes to an open board in this release, so a removed member goes on reading the board they already loaded and meets the removal on the first thing they try to change.

Running the workspace

Configuration → Workspace, on a Cloud board:

• See who is in it, and — as an owner — add somebody by GitHub handle, change a role, or take somebody off.
• Rename it, and see the execution nodes — the machines allowed to run this board's work, each named with whose machine it is. Any member registers and renews their own; an owner renames one or takes one off.
• Export to a folder. The whole board as Markdown, the archive included, into a folder you choose; that folder opens as a Local board. The preview keeps no backups, so an export you have made is the only copy anybody can restore from.
• Leave Cloud. The board is written back into docs/kanban/, the pointer comes off, and the docs/kanban/ block leaves the root .gitignore — again as one commit you read first, so the board you get back is one git tracks. The workspace stays where it is.
• Delete the workspace. An owner's move. Everything in it goes, for everybody in it, and this checkout stops pointing at it. There is no grace window and no backup — export first.

Reading a Cloud board in a browser

A Cloud board also has a URL: cloud.ai4kanban.dev/<workspace-id>, and a card at cloud.ai4kanban.dev/<workspace-id>/<card-id>. Open it on a second computer, a borrowed laptop or a phone — anywhere the app is not installed — and sign in with GitHub there. The browser sign-in and your machine's are separate: ending either one leaves the other signed in.

cloud.ai4kanban.dev on its own lands you on your workspace, or lists them by name when you have more than one, so a device holding no link still gets to the board.

It reads; it does not write. The board and its cards, whole — the human half, the folded agent half, the subtasks and the open questions — with the release picker and the way back, and nothing else. There is no chat, no Create task and no card action, so nothing you press in a browser changes the board. Answering the agent from a browser comes later.

No board is on the open web. Every page is for the account the workspace belongs to and refuses everyone else. A signed-out visitor, an account the workspace is not for, a deleted workspace and a made-up id all meet the same sentence, so none of them learns whether that workspace exists; every page is noindex, and a link pasted into a chat previews nothing of the board. There is no way to publish a board for anyone to read.

The page draws in your browser's own language — English or Simplified Chinese — since there is no app here holding your setting. The board's own words travel in whatever language they were written.

When a checkout cannot read its workspace

A workspace that was deleted and one this account is not in meet the same refusal, on purpose: nothing leaks whether a workspace ever existed. The board says so in one sentence and names the two ways out — ask an owner to add you, or leave Cloud and take the markdown that is in the folder.

What Cloud never gets

Cloud manages board coordination and nothing else. It never receives your repository, never runs an agent, and never reads a card the board has not published. A workspace holds this board — its cards, memory, releases and history — and nothing around it.