Workspaces

A workspace keeps your repositories together between visits: who can see them, how they are connected, and what to do when two of them disagree.

Creating a workspace

A workspace is the persistent, private counterpart of a demo session, and it needs a Kimtu account. You can create one from scratch, or save a ready demo as one: the demo's repository becomes the workspace's first, and the manifest and attached documents are copied across. A demo can only ever become a new workspace; a repository joins an existing one through the connect flow.

Connecting repositories

Each repository syncs on its own, by running its prompt again in your own coding agent. See Syncing for what is sent and what replaces what.

One manifest each: A repository is identified by the repository.id in its kimtu.yaml, unique within the workspace. A monorepo declares all its components in one file.
Connecting: Connecting a repository gives it an id and a prompt. The prompt tells your coding agent which id to write, so the first upload already matches, and syncs with the kimtu CLI as you, so it holds no secret.
CI tokens: For a CI job, which has nobody to sign in: issued on demand from the repository's page. kimtu_rt_ followed by 256 random bits, shown once, for that repository alone; it never expires and can be revoked. A repository can hold several, so one can be replaced without a gap; the last-used time beside each makes a forgotten one stand out.
Uploads replace: An accepted upload replaces that repository's manifest and documentation and nothing else. A rejected one changes nothing.
Renaming and removing: Rename a repository in the workspace and its tokens, upload log and component claims follow. Removing one drops its part of the map; relationships elsewhere that pointed at its components become undeclared placeholders.
Never stale: A repository shows when it last synced and the commit the agent sent. Nothing is marked stale: Kimtu cannot tell what current means for somebody else's repository.

After a successful sync, the prompt also offers to add a short block to AGENTS.md or CLAUDE.md pointing future agents at the command line. It shows you the file and the exact text and changes nothing until you agree.

Members

Same rights: Every member can invite people, remove members, connect, rename and remove repositories, issue and revoke CI tokens, rename the workspace, and create and revoke share links. There are no roles.
The creator: Only the creator can delete the workspace, and the creator cannot leave or be removed, so leaving means deleting.
The slug: Chosen at creation, it is in every URL and never changes. The name can change at any time.
Removal: A removed member loses access within about a minute.
Not a member: A workspace you do not belong to, one that does not exist and a mistyped address all answer the same 404.

A share link lets someone without an account read the workspace. It is a capability URL: possession is the permission.

What it grants: Reading, and nothing else. Anyone holding the link can read, signed in or not.
What a reader sees: The map, data flow, components, documentation, the workspace's issues, its repositories and when each last synced, and members' names.
What a reader never sees: Tokens, the upload log, rejected attempts, or anyone's email address. A member with no name is left out rather than shown by email.
Expiry: Chosen when you create it: never, 7, 30 or 90 days. A workspace can have several links, so one sent to one person can be revoked alone, and revoking takes effect at once.
Unknown links: A revoked, expired or unknown link is the same 404, so a stranger cannot tell which. Shared pages are kept out of web results.
What is counted: How many times a link was opened and when it was last opened. Nothing about who opened it.

Issues

When several repositories describe one system they will sometimes disagree. Kimtu reconciles them with one rule per case and lists what it did on the Issues page. Severity has three levels, and a note never asks anyone to act.

A conflict never blocks: An upload is rejected only for problems in its own repository's files. A conflict with another repository never rejects it; it appears here, for every member.
Two repositories, one id: The earliest to claim an id keeps it. The later declaration, and the relationships written on it, are dropped, with an OWNERSHIP_CONFLICT warning.
External systems: A component one repository owns and another lists under external: is one component: the owner wins. Several repositories listing the same external merge field by field, and a mismatch is an EXTERNAL_DECLARATION_MISMATCH note.
The same link twice: A link declared from both ends is one edge, in the direction data moves, with both declarations kept as its sources.
Unknown document target: A document that names a component nobody declares stays attached to its repository, with a DOC_REFERENCE_NOT_FOUND warning.
Order never matters: Who wins is decided by when each repository began declaring an id, not by which synced last, so the result is the same whatever order things arrive in.

Limits

These bound abuse; they are not a billing model.