Public projects, workbenches and outside help

How a project is found, read and worked on by people who are not its members, and how its address names its owner. Decided with the owner on 2026-09-24/25 (#351, #322, #350, #357; decisions in memories #353 and #356). WEB.md in the repository holds the same rules in short.

flowchart LR
  V[Visitor, no account] -- reads --> P[Public project\n/owner/project]
  O[Signed in, outside] -- reads, stars --> P
  O -- claims up to 3 tasks,\nmarks done --> Q[Proposal]
  O -- opens --> W[Workbench\n/you/project]
  W -- recall reads --> P
  W -- shared memory --> Q
  Q -- moderator confirms --> P
  M[Member] -- writes --> P

Addresses

• A project lives at /{owner}/{project}, for example /Matt-17/Conderis, and every section below it: /overview, /memories, /tasks, /docs, /settings. New projects are created at /new.
• The owner is the username (handle) of the project's organization, or of the person who owns it. People and organizations share one namespace. A username keeps the case it was chosen in and is compared without it; it has 2 to 39 characters, letters, digits and single hyphens, and may not be one of the site's own first path segments (Handles.Reserved). Add every new top-level page there.
• The project segment is the project name's letters and digits in their case, joined by hyphens, and unique per owner (ProjectSlugs.FromName, Project.Path, unique NormalizedPath).
• Someone signed in without a username is sent to /username before any other page (legal pages excepted). New accounts choose it there after their first sign-in; the migration of #351 gave the two accounts of the time Matt-17 and smoke-test.
• A project whose owner has no username has no address: its path is a placeholder, ~ and its id, that no route matches. It moves under the username once there is one. There is no /projects address any more, and no redirect from the addresses before #351.
• Every address a project leaves later - a renamed project, a renamed owner - is kept in ProjectRedirects and answers 301 to the same page at the new address, but only to someone who may read the project. To anyone else it answers like an unknown address, so a redirect never confirms that a private project exists. An old address stops redirecting when another project takes it.
• README badges answer at the current address and at every address the project left: /{owner}/{project}/badge.svg.

Private and public

• A project is private or public, as on GitHub. The owner changes it in person under Settings › Danger zone › Change visibility, confirming by typing the project's address; an agent key cannot (KnowledgeService.SetPublic). A verified repository is not required; verification only marks the project as the repository's own.
• Everyone, also without an account, reads a public project: its tasks, its shared memories, pages and instructions, and the names of its members and agents. Private memories stay with their author. Writing stays with members, except what outsiders may do below.
• A visitor without an account is Actor.Anonymous (user id empty). KnowledgeService.Validate lets it read and refuses every write. Project pages carry no [Authorize]; whatever a visitor may not read - a private project, an unknown address, settings, editors - redirects to sign-in, the same for all of them.
• Browse projects (/explore, top right on every page) lists public projects that have an address, for everyone. Visitors' page requests are limited to 240 a minute per IP.
• Project lists - the sidebar, the home list, project_get without an id - hold only the projects one works in plus starred ones. Others' public projects are read by id or address, and found under Browse projects.

Star

The sparkle on someone else's public project adds it to your lists (#350): it appears under Favorites in the sidebar, the home list and your agents' project_get. On your own projects the same sparkle keeps them on top. A star gives no rights, and the project leaves your lists when you remove the star or it turns private. It is a ProjectFavorites row; KnowledgeService.WorksIn tells a starred project from one you work in.

Workbench

A workbench is your own project on someone else's public project - what the code calls a fork and agents see as upstream (Project.UpstreamProjectId). Open a workbench on a public project creates it under your username with the original's name, one per original (KnowledgeService.OpenWorkbench); the button then reads Your workbench.

• Its tasks and private memories stay yours; the original never sees them.
• Recall in the workbench brings the original's shared memories along and names the original's free tasks, read only, with its project id.
• The Tasks tab shows the original's open tasks under your own, read only; open one there to claim it.
• A new shared memory stored in your workbench goes to the original instead (KnowledgeService.ForWorkbench): a proposal for its moderators, or published if you moderate the original. A key allowed to write the workbench may make that proposal, and nothing else in the original. MCP answers with the original's projectId and whether it waits.
• 'Shared' in a workbench therefore always means 'for the original'; a team inside one workbench shares nothing with each other yet.

Helping from outside

Like GitHub issues (#357). Anyone signed in who is outside a public project (not owner, organization or member) and not blocked may:

• Claim a free task. A task someone else holds is refused as for members. At most 3 open top-level tasks per person and project, counting the person's agents; subtasks do not count (TaskService.OutsideClaimLimit).
• Release their own claim: item_store task with assignee: null, or Release on the task page. Nothing else about the task changes from outside.
• Mark as done: item_action complete from outside creates a proposal (ProjectChange with kind task, operation complete) instead of closing the task (TaskService.CompleteOrPropose). The task stays open and theirs until a moderator confirms it done (TaskService.CompleteConfirmed) or turns it down.

Members keep everything else: editing, closing, archiving, deleting, priorities. They may release an outside claim or give a task to anyone with a workbench on the project, a member, or the owner or the owning organization.

Moderators block a person under Settings › Blocked from contributing, by username (ProjectBlocks, TaskService.SetBlocked). Blocking gives back every open task the person or their agents hold there, and a blocked person can neither claim nor propose; reading stays open, as for everyone. Members are removed, not blocked. There is no switch to turn outside help off, and nobody is blocked by default.

Proposals from outside

A memory or page written from outside a public project, and a task marked done from outside, become proposals (see Review and proposals). They are decided in Moderation or on the item's own page. Approval checks that the proposer is not blocked; in a public project it needs no membership.