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 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 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/, kept in step with the workspace. 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.

Archived cards are deleted from the workspace after a while, as on a Local board. A Local board still has them in git history; a Cloud board does not, so export first to keep them.

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.

A board already open moves from Configuration → Cloud. The Cloud storage switch there carries the whole board — cards, archive, memory and project settings — into a new workspace; your own agent and workflow settings stay on each machine, named after your project folder unless you type something else. It asks first, and it never joins a workspace your account already has, so one move is one workspace. It is in the app only, and only for an account we have admitted to the preview.

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.

Coming back to Local

The same Cloud storage switch, turned off. The workspace is written back into docs/kanban/ whole, and the repository is left holding the reverse of those three changes — again as one commit you read first, so the board you get back is one git tracks. The workspace itself stays where it is and keeps everything in it; deleting it is a separate move on Configuration → Workspace.

The board stops while it moves, either way. A run still going finishes first, and it is listed while you wait, so nothing it writes is left behind; then the whole window becomes the migration page until the move ends. There is no restart and no reopening the project. A move that fails leaves the board exactly where it was, and says why.

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 this workspace. Offered only where Cloud says this workspace is no longer yours — deleted, or never this account's. There is nothing to write back, so it only stops the checkout reading it; the ordinary way back to Local is the Cloud storage switch above.
• 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

Open cloud.ai4kanban.dev on any device and sign in with GitHub to read your board and its cards, without the app. It reads only — nothing you press there changes the board. Only your workspace's members can open it; no board is public.

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 the workspace 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 and history — and nothing around it.