What this means for a prototype

THREE KINDS OF CONSTRAINT·none of them is a product feature request

25MUST PRESERVEa Gen-5 distinction or constraint an interface cannot erase

41MUST NOT ASSUMEa tempting behaviour Gen-5 does not guarantee

1NOT PRESCRIBEDa choice Gen-5 is silent on, stated only where a source shows that silence

Every entry names the claim groups or records it derives from, and carries no state of its own.

Derived from the published System Guide. Every row cites the claim groups it renders, and every rule on it is quoted from one of them.

Each domain chapter ends with What this means for a prototype, in three parts. Must preserve: a Gen-5 distinction or constraint an interface cannot erase. Must not assume: a tempting behaviour Gen-5 does not guarantee. Not prescribed: a choice Gen-5 is silent on, stated only where a source shows that silence. Empty parts are left out.

Every entry names the claim groups or records it derives from. It carries no state of its own; Representation B shows the state of each cited group or record. The consolidated list of prototype rules is generated from the three chapter blocks (P1, P2, P3); it is never written separately.

Consolidated list

Generated from the three chapter blocks (Workspaces, Projects, Tasks). It is never written separately, and it carries no state of its own: each entry shows the state of the claim groups or records it cites.

MUST PRESERVE25

Workspaces

Ownership is its own fact about a workspace, separate from anyone's role; an interface must never derive it from, or present it as, a role value.fromWS-OWN-2WS-OWN-3
Every workspace has exactly one owner at every moment.fromWS-OWN-1
The Personal Workspace and user-created workspaces are distinct kinds.fromWS-KIND-1WS-KIND-2
Roles belong to one workspace or one project; the same person can hold different roles in different places.fromWS-ROLE-5
An ended membership stays ended; coming back is a new membership.fromWS-MEM-2
Every account has its Personal Workspace unconditionally; nothing an operator, a catalogue or the beta programme controls can withhold it.fromWS-KIND-1
Authorization to create a further workspace and permission for a template are two separate permissions; an interface must not merge them into one idea of "access".fromWS-KIND-3

Projects

Workspace membership and project membership are separate; being in a project at all — not merely reaching its tasks — needs a person's own project membership.fromPJ-ACC-1
Joining a workspace opens no project and no project chat, in every kind of workspace.fromPJ-ACC-4
An interface must work for a member who has workspace access, no projects and no project chats: that state is correct and needs no repair.fromPJ-ACC-7
The workspace owner is an admin member of every active project, for as long as they can reach the workspace — as a membership, never as a role named "owner", and never as access without one.fromPJ-ACC-6PJ-ACC-2PJ-ACC-10
A project's owner is always the workspace's owner; it is never set, stored or changed per project.fromWS-OWN-4
The main project cannot be archived on its own.fromPJ-MAIN-1
Archiving closes unfinished tasks as part of the archive action, with the archival as the reason — not as ordinary cancellations.fromPJ-ARCH-2XD-SYS-1
Archiving reassigns nothing; assignee and reviewer stay as recorded.fromPJ-ARCH-3

Tasks

State, assignee and reviewer are three separate facts; changing one never changes another.fromTK-DIM-1TK-ASG-4
A task's reviewer is a responsibility on that task, never a role, and a different position from its assignee.fromTK-REV-1
The assignee and the reviewer of one task are never the same person, in either direction and whoever is acting.fromTK-REV-9
Choosing a task's reviewer is a separate authority from moving the task; the assignee has the second and not the first.fromTK-REV-7
Positions combine: an assignee who is also the creator, a project admin or the owner keeps everything those positions allow.fromTK-REV-8
Exactly six states, with the display names Open, In Progress, Blocked, Ready for Review, Complete, Canceled.fromTK-LC-1
Finished tasks never move again; entering Ready for Review needs a reviewer, and only someone who may choose reviewers can supply one on the way in; a person moving a task to Blocked, or canceling it, adds a comment.fromTK-LC-3TK-REV-3
From Ready for Review, close-out belongs to the owner, a project admin or the task's reviewer.fromTK-REV-4
A task's history is one ordered timeline of both kinds of entry, and entries are never edited.fromTK-HIS-1TK-HIS-2
"My tasks" covers tasks a person is assigned to or reviews.fromTK-REV-6

MUST NOT ASSUME41

Workspaces

That a member's role can read "owner", or that the owner can be found from roles.fromWS-OWN-2WS-OWN-3
That an owner can hand over, or leave, their workspace today.fromWS-OWN-6DNA-1
That a workspace can be archived, or deleted, from inside ChatWell today.fromWS-LIFE-1DNA-2
That an owner can change a member's workspace role after they joined, today.fromDNA-6
That a workspace role is fixed forever: Gen-5 has decided the owner may change it, though that is not available today.fromDNA-6
That an account can create a further workspace: during beta it needs authorization and a permitted template, and an account has neither until ChatWell's operators grant them.fromWS-KIND-3WS-KIND-6
That the product offers a way to ask for, or grant, that authorization.fromWS-KIND-6
That "free" describes a plan, a tier or a price. It describes only that every account has a Personal Workspace.fromWS-KIND-5
That a template is available to everyone: none is, at this product stage.fromWS-KIND-7
That removing a member always succeeds without naming a replacement reviewer, or that any member can be that replacement.fromWS-MEM-6WS-MEM-7
That leaving always succeeds: the owner cannot leave, and for a reviewer of active tasks the sources disagree.fromWS-OWN-6SD-1

Projects

That a workspace admin is automatically in every project.fromPJ-ACC-2
That the owner can see a project's tasks because they own the workspace: they see them through the membership the guarantee gives them, and an archived project gives them none.fromPJ-ACC-2PJ-ACC-6PJ-ACC-9
That because the owner can see a project, they can see its tasks.fromPJ-ACC-5PJ-ACC-2
That the owner's project membership exists when the owner has lost access to the workspace, or that it is written back over that time if they return.fromPJ-ACC-10
That joining a workspace adds a project, a main project or a project chat.fromPJ-ACC-4
That a member who shows no projects is an error state, an empty result to be filled in, or a sign that something failed.fromPJ-ACC-7
That nobody has a project they did not receive explicitly: memberships made before this rule remain.fromPJ-ACC-8
That an archived project can be reopened, restored or exported today.fromPJ-ARCH-1XD-ARCH-1DNA-4
That a project admin can change project roles.fromPJ-ROLE-1
That the owner can be removed from, demoted in, or made to leave an active project.fromPJ-ACC-11
That losing ownership of a workspace would strip the outgoing owner's project memberships.fromDNA-1
That role changes appear in history today.fromDNA-10
That removing someone from a project always succeeds without naming a replacement reviewer, or that any member can be that replacement.fromPJ-ACC-3WS-MEM-7
That leaving a project always succeeds, or always hands a reviewer's tasks on: the sources disagree.fromSD-1
That the history entries written by archiving a project name the person who archived it, or that they name no one: the sources disagree.fromSD-2

Tasks

That "assigned" is a state, or that an assignee accepts or declines a task.fromTK-DIM-2
That assigning someone starts the work.fromTK-ASG-4
That close-out from review is reserved to the reviewer: the owner and a project admin can close it out too.fromTK-REV-4
That whoever may send a task to review may also choose its reviewer on the way.fromTK-REV-3TK-REV-7
That an assignee can always hand their work on: with no reviewer in place and nobody who may name one, the handoff does not happen.fromTK-REV-11
That assignees may never choose a reviewer — an assignee who is also the creator, an admin or the owner may.fromTK-REV-8
That a task's creator may not review it: they may, unless it is assigned to them.fromTK-REV-10
That the reviewer or the assignee can change a task's reviewer.fromTK-REV-5
That a recorded reviewer is replaced without an owner or admin naming someone.fromTK-REV-2
That a task's creator belongs in "my tasks" as creator.fromTK-REV-6
That tasks can be deleted, or comments edited, today.fromTK-DEL-1TK-HIS-5
That a finished task can be reopened, continued or duplicated today.fromTK-LC-3TK-CONT-1
That comments have unread counts.fromTK-HIS-7
That a project's default reviewer can be chosen today.fromDNA-11
That a reviewer who leaves on their own either hands their reviews on or is refused: the sources disagree.fromSD-1

NOT PRESCRIBED1

Tasks

Gen-5 does not prescribe how a task's state is rendered, for example as a pill or a colour.fromTK-LC-1