Projects
PJ-MAIN-1WS-START-1Derived from the published System Guide. Every row cites the claim groups it renders, and every rule on it is quoted from one of them.
You are in: Projects. This assumes only the core model (T1).
P2.1What a project isPermalink
PJ-WHAT-1A project belongs to exactly one workspace and is either active or archived.
Tasks live in projects. A project can be archived on its own; that leaves its workspace and the workspace's other projects unchanged.
Why is this true?
PJ-WHAT-1Fulla fact about the sources, not a reader labelExact identity
PJ-MAIN-1Every workspace has one main project, which cannot be archived on its own.Partly defined
It is created together with the workspace. Partly defined.
Why is this true?
PJ-MAIN-1Partly defineda fact about the sources, not a reader labelExact identity
PJ-CRE-1The owner and workspace admins can create projects.Partly defined
The person who creates a project becomes an admin of it, and the project gets a General Chat. When someone other than the workspace owner creates it, the owner becomes an admin of it too (P2.2). Partly defined.
Why is this true?
PJ-CRE-1Partly defineda fact about the sources, not a reader labelExact identity
admin project membership; never a duplicateadmin project membership where the creator is someone elseRuntime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
PJ-EDIT-1An admin of the project, or the workspace owner, can change a project's name, its other details, and its type.Partly defined
Partly defined.
Why is this true?
PJ-EDIT-1Gapa fact about the sources, not a reader labelExact identity
The owner of the workspace is the owner of every project in it (P1.2).
P2.2Project membership and accessPermalink
PJ-ACC-1Belonging to a workspace gives no project membership at all.
Being in a workspace is never by itself a way into a project inside it. To be in a project — and so to see its tasks and work on them — a person needs their own membership in that project, as well as access to the workspace and an active project.
Why is this true?
PJ-ACC-1Fulla fact about the sources, not a reader labelExact identity
PJ-ACC-2This holds for admins and for the owner too.
A workspace admin who is not a member of a project cannot see it or its tasks. The owner, though owner of every project, sees and works on a project's tasks only while a member of that project. Ownership is not a way past membership — it is a reason the owner has one (PJ-ACC-6).
Why is this true?
PJ-ACC-2Fulla fact about the sources, not a reader labelExact identity
admin project membership and nothing more; ownership alone never obliges onePJ-ACC-4Accepting a workspace invitation gives the workspace, and no project inside it.
No project comes with it — not the workspace's main project, not that project's chat, not any other project. This is the same in every kind of workspace, Personal Workspaces included.
Why is this true?
PJ-ACC-4Fulla fact about the sources, not a reader labelExact identity
accept invitation opens W alone and never a P, in every workspace type, the default/main project included; §3 policy — belonging to a workspace opens no P at allRuntime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
PJ-ACC-7A member with no projects at all is a correct state.
Someone can belong to a workspace, hold no project membership and see no project chat, and nothing is wrong: ChatWell will not quietly hand them a project to fill the gap. They stay that way until someone gives them a project.
Why is this true?
PJ-ACC-7Fulla fact about the sources, not a reader labelExact identity
Runtime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
PJ-ACC-8Project memberships that already exist are left alone.
An earlier version of ChatWell did add people to a project when they joined a workspace. Those memberships are still real memberships and are not taken away; what changed is that joining adds no new ones.
Why is this true?
PJ-ACC-8Fulla fact about the sources, not a reader labelExact identity
PJ-ACC-3People are added to projects one project at a time.Partly defined
An admin of the project, or the workspace owner, adds a current workspace member. A project admin can add people only as members. Leaving or being removed from a project ends only that project membership; the person stays in the workspace. Removing someone who reviews active tasks in the project needs a replacement reviewer named as part of the removal — one person for the whole project, and never someone already responsible for one of those tasks (P1.3). Partly defined.
Why is this true?
PJ-ACC-3Partly defineda fact about the sources, not a reader labelExact identity
PJ-ACC-6The workspace owner is a member of every active project in their workspace, with the admin role.
Nobody grants it and nobody has to remember to: for as long as a project is active and the owner has access to the workspace, the membership is there, whoever created the project. It is an ordinary membership carrying the admin role — there is still no role called "owner", and owning a project is still worked out from owning the workspace rather than stored (P1.2).
Three things follow from it:
Why is this true?
PJ-ACC-6Fulla fact about the sources, not a reader labelExact identity
owner does not become a project role and project ownership is still derived and stored nowhereRuntime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
PJ-ACC-9Only active projectsAn archived project is outside the guarantee.
Archiving ends the owner's membership in it along with everyone else's, and nothing reopens it.
Why is this true?
PJ-ACC-9Fulla fact about the sources, not a reader labelExact identity
admin membership in the same transaction, as a new episode; there is no project-restore operation todayPJ-ACC-10Only while the owner can reach the workspace.
Owning a workspace does not by itself give access to it. If an owner's own access ever ended, they would be owed no project membership, none would be created for them, and the project memberships they hold could close under the ordinary rules — that would be correct, not a fault. Nothing in ChatWell today ends an owner's access to their own workspace, so this does not arise.
Why is this true?
PJ-ACC-10Fulla fact about the sources, not a reader labelExact identity
PJ-ACC-11It holds the owner in place.
While a project is active, the owner cannot leave it, cannot be removed from it, and cannot be moved down to the ordinary member role in it.
Why is this true?
PJ-ACC-11Fulla fact about the sources, not a reader labelExact identity
Runtime evidence is never an authority of its own. An accepted document says the same thing first; the evidence says only that the running system agrees.
PJ-ACC-5Partly defined. Outside tasks, the workspace owner currently sees every project in the workspace, with its member list and chat, and can manage its members, roles and archiving, whether or not they are a member of it.Partly defined
For active projects this changes nothing they would not have anyway (PJ-ACC-6); it still matters for archived ones, where the owner holds no membership and keeps this reach (P2.3). No registered document describes that reach; the canonical rules give ownership no access of its own.
Why is this true?
PJ-ACC-5Gapa fact about the sources, not a reader labelExact identity
PJ-ROLE-1Inside a project, members are member or admin, and changing that role works today — for the workspace owner.Partly defined
Every change between member and admin needs the workspace owner; a project admin cannot make or remove project admins. The one role nobody can lower is the owner's own, in an active project: it stays admin (PJ-ACC-6). Partly defined.
Why is this true?
PJ-ROLE-1Partly defineda fact about the sources, not a reader labelExact identity
admin in every ACTIVE project, so it cannot be lowered therePJ-ROLE-2Changing a role does not interrupt membership.
It neither ends nor restarts the person's project membership.
Why is this true?
PJ-ROLE-2Fulla fact about the sources, not a reader labelExact identity
Leo holds workspace membership and no project at all. That is a correct state, not a fault (PJ-ACC-7).
P2.3Archiving a projectPermalink
PJ-ARCH-1An admin of the project, or the workspace owner, can archive any project except the main one.Partly defined
Archiving is one-way today: there is no way to reopen the project. Partly defined.
Why is this true?
PJ-ARCH-1Partly defineda fact about the sources, not a reader labelExact identity
PJ-ARCH-2The archive action closes the unfinished work.
Every task in the project that is not already Complete or Canceled becomes Canceled, with the archival recorded as the reason. The archive action does this itself, and each task's history records the move to Canceled.
Why is this true?
PJ-ARCH-2Fulla fact about the sources, not a reader labelExact identity
PJ-ARCH-3Nothing is reassigned, and memberships end.
The project's memberships end with the archival as the reason — the workspace owner's among them, since the standing guarantee covers active projects only (PJ-ACC-9). Assignees and reviewers stay recorded as they were when the project closed. The workspace and its other projects are not touched.
Why is this true?
PJ-ARCH-3Fulla fact about the sources, not a reader labelExact identity
PJ-ARCH-4Afterwards, nobody can open or change the project's tasks through ChatWell today — not its members, not the workspace owner — and no new tasks can be created in it.
The content is kept (T2.6).
Why is this true?
PJ-ARCH-4Fulla fact about the sources, not a reader labelExact identity
PJ-ARCH-5Partly defined. Outside tasks, the workspace owner currently keeps more:Partly defined
they still see an archived project in their project list, can read and post in its chat, can see its past memberships, can still change its name, details and type, and can add current workspace members to it. Anyone added this way gets the project, its member list and its chat back — never its tasks. The decided rule closes archived content to ordinary access, and no registered document describes these exceptions.
Why is this true?
PJ-ARCH-5Gapa fact about the sources, not a reader labelExact identity
Sources disagree: whom the archival cancellations namePermalink
Sources disagree. Whom a task's history names as having acted, for the cancellations written when a person archives a project.
The task lifecycle & assignment model, and one part of the Gen-5 task implementation specification, say Another part of the Gen-5 task implementation specification says Archival closes these tasks with no human actor: the entries name no one as having acted. The entries name the person who archived the project as having acted. This guide does not choose between them. The disagreement stands until the owners of those sources resolve it.
Meanwhile: assume neither — neither that these entries name the person who archived the project, nor that they name no one.
Not affected: that archiving cancels the project's unfinished tasks automatically (PJ-ARCH-2); that each task records the archival as the reason it closed (XD-SYS-1); that these entries carry no creator, assignee or reviewer markers (TK-HIS-3); and who can reach an archived project's tasks (XD-ARCH-1).
Classification: Sources disagree (newly surfaced in this pilot; bounded to the actor named on archival cancellation entries). The accepted implementation was not used to adjudicate it.
Exact identity
The same action cancels the project's unfinished tasks (P2.3). No transition leads back from Archived today.
PJ-ARCH-1What this means for a prototype — ProjectsPermalink
Every entry names the claim groups or records it derives from. It carries no state of its own; the state shown on each chip is that of the group or record cited.
MUST PRESERVE
- 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.from
PJ-ACC-1 - Joining a workspace opens no project and no project chat, in every kind of workspace.from
PJ-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.from
PJ-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.from
PJ-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.from
WS-OWN-4 - The main project cannot be archived on its own.from
PJ-MAIN-1 - Archiving closes unfinished tasks as part of the archive action, with the archival as the reason — not as ordinary cancellations.from
PJ-ARCH-2XD-SYS-1 - Archiving reassigns nothing; assignee and reviewer stay as recorded.from
PJ-ARCH-3
MUST NOT ASSUME
- That a workspace admin is automatically in every project.from
PJ-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.from
PJ-ACC-2PJ-ACC-6PJ-ACC-9 - That because the owner can see a project, they can see its tasks.from
PJ-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.from
PJ-ACC-10 - That joining a workspace adds a project, a main project or a project chat.from
PJ-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.from
PJ-ACC-7 - That nobody has a project they did not receive explicitly: memberships made before this rule remain.from
PJ-ACC-8 - That an archived project can be reopened, restored or exported today.from
PJ-ARCH-1XD-ARCH-1DNA-4 - That a project admin can change project roles.from
PJ-ROLE-1 - That the owner can be removed from, demoted in, or made to leave an active project.from
PJ-ACC-11 - That losing ownership of a workspace would strip the outgoing owner's project memberships.from
DNA-1 - That role changes appear in history today.from
DNA-10 - That removing someone from a project always succeeds without naming a replacement reviewer, or that any member can be that replacement.from
PJ-ACC-3WS-MEM-7 - That leaving a project always succeeds, or always hands a reviewer's tasks on: the sources disagree.from
SD-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.from
SD-2
Where this comes from — ProjectsPermalink
Where this comes from22 claim groups
| Claim group | Covers | State | Coverage | Sources |
|---|---|---|---|---|
PJ-WHAT-1 | What a project is | Works today | Full | Workspace & project lifecycle model · Accepted Gen-5 implementation |
PJ-MAIN-1 | The main project | Works today | Partly defined | Membership model · Accepted Gen-5 implementation |
PJ-CRE-1 | Who creates projects | Works today | Partly defined | Project access policy decision · Membership model · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
PJ-EDIT-1 | Changing a project's name, details and type | Works today | Gap | Accepted Gen-5 implementation |
PJ-ACC-1 | Project access needs membership | Works today | Full | Membership model · Accepted Gen-5 implementation |
PJ-ACC-2 | Also for admins and the owner | Works today | Full | Workspace & project lifecycle model · Project access policy decision · Gen-5 task implementation specification · Accepted Gen-5 implementation |
PJ-ACC-6 | The owner's standing project membership | Works today | Full | Project access policy decision · Membership model · Workspace & project lifecycle model · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
PJ-ACC-9 | Active projects only | Works today | Full | Project access policy decision · Membership model · Accepted Gen-5 implementation |
PJ-ACC-10 | Conditioned on the owner's own access | Works today | Full | Project access policy decision · Membership model · Workspace & project lifecycle model · Accepted Gen-5 implementation |
PJ-ACC-11 | The owner cannot leave, be removed or be demoted | Works today | Full | Project access policy decision · Task lifecycle & assignment model · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
PJ-ACC-3 | Adding and removing people | Works today | Partly defined | Membership model · Workspace & project lifecycle model · Task reviewer authority decision · Task operation contract · Accepted Gen-5 implementation |
PJ-ACC-4 | Joining adds no project | Works today | Full | Project access policy decision · Membership model · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
PJ-ACC-7 | Zero projects is correct | Works today | Full | Project access policy decision · Membership model · Accepted Gen-5 implementation · Accepted runtime evidence (R1–R4) |
PJ-ACC-8 | Earlier memberships are kept | Works today | Full | Project access policy decision · Membership model · Accepted Gen-5 implementation |
PJ-ACC-5 | Owner reach outside tasks | Works today | Gap | Accepted Gen-5 implementation · Gen-5 task implementation specification · Project access policy decision · Workspace & project lifecycle model |
PJ-ROLE-1 | Changing project roles | Works today | Partly defined | Workspace & project lifecycle model · Project access policy decision · Accepted Gen-5 implementation |
PJ-ROLE-2 | Role change keeps membership | Works today | Full | Membership model · Accepted Gen-5 implementation |
PJ-ARCH-1 | Who archives; one-way today | Works today | Partly defined | Workspace & project lifecycle model · Accepted Gen-5 implementation |
PJ-ARCH-2 | Archive closes unfinished work | Works today | Full | Gen-5 lifecycle decisions · Gen-5 task implementation specification · Accepted Gen-5 implementation |
PJ-ARCH-3 | Nothing reassigned | Works today | Full | Workspace & project lifecycle model · Task lifecycle & assignment model · Project access policy decision · Accepted Gen-5 implementation |
PJ-ARCH-4 | Tasks closed to everyone | Works today | Full | Task lifecycle & assignment model · Gen-5 task implementation specification · Accepted Gen-5 implementation |
PJ-ARCH-5 | Owner exceptions outside tasks | Works today | Gap | Accepted Gen-5 implementation · Workspace & project lifecycle model · Source of Truth Map |
Coverage is a fact about the sources, not a reader label. Gap is not one of the five labels.