Add private, organization and public visibility to project tasks #205

Corrected user intent

All tasks remain attached to a project. This feature adds visibility, not personal/organization task scopes or standalone task namespaces. The earlier scope interpretation is superseded by this description.

Proposed visibility

• Private: visible to the owning user and their explicitly authorized agents. Clarify ownership versus creator attribution in the first design child.
• Organization: visible to authorized members/agents of the project's associated organization.
• Public: readable publicly when the project is explicitly public. An open-source repository alone does not automatically publish its tasks.

Access rules

Visibility grants read reach only; write, assignment, claim and completion still require appropriate capabilities. Project access is an additional upper bound: organization visibility does not bypass private-project restrictions. Do not offer organization visibility without an associated organization, or public visibility in a private project. Define authorized owner access and whether moderators have any private-task access explicitly; no implicit broad access.

Compatibility

Retain ProjectId, canonical project item numbers, project routes and task/memory numbering. Map existing tasks according to their actual previous access; do not mass-publish previously restricted tasks. Specify handling for legacy access patterns that do not match the three choices exactly before migration. New tasks default to private unless a separately documented explicit creation choice is made.

Hierarchy and changes

Subtasks default to the parent's visibility and cannot be broader than an ancestor. Narrowing visibility must handle descendants, assignments, links, counts, live notifications and recall atomically or reject with a clear resolution path. Restricting a project immediately suppresses public task access; define safe behavior when it becomes public again. Public task reads must never expose private relatives, notes or assignee contact data.

Acceptance

• Every task still belongs to one project and retains its existing reference.
• Private, organization and public reads match the approved access matrix in UI and MCP.
• Visibility changes are explicit, authorized and concurrency checked.
• Parent/child links, search, recall, ready work, counts and events reveal no hidden task content.
• Public means readable, not editable or claimable by anonymous visitors.

Agent handoff

Planning only. Replace the prior scope proposal entirely. #207 defines semantics; #208 migration; #209 services; #210 MCP; #211 UI; #212 verification.