Generalize change proposals and moderation across memories, project instructions and tasks #226

Goal

One proposal/review workflow for project memories, Project Instructions and tasks. Contributors suggest changes; only approval changes published content. Dashboard and MCP share services and permissions.

Context

Memory revisions already support reviews. Instructions publish directly for owners/moderators (MCP push implemented in efd71aa; verify deployment). Tasks have direct writes/version checks only. Coordinate with #205 (task visibility), #213 (canonical references), #97 (closeout suggestions) and #76 (task rules).

Model and lifecycle

• Common proposal: stable public ID, projectId, target kind/reference, operation, base revision/version, typed changes, explanation, author/agent, timestamps, decision/reason and concurrency version.
• Pending -> approved/rejected/withdrawn. Authors may withdraw pending proposals; revised submissions are immutable revisions. Distinguish proposer from reviewer.
• Canonical project references for memories/tasks; projectId for instructions. Do not guess internal IDs or confuse proposal IDs with task numbers.
• Retain proposals for new shared/public memories; support updates to all three types and initial Instructions publication. Task fields: title, description, status, priority, assignment. Omitted fields preserve values; null follows existing clearing rules.
• Approval atomically rechecks target, base version, submitter/reviewer access and domain rules, then publishes once. Stale proposals show conflicts and require explicit rebase/resubmission.
• Pending/rejected/withdrawn content never becomes current content, recall guidance, ready work or assignment state.

Permissions

• Define/test each type's matrix for readers, contributors, owners/moderators and authorized external public-project contributors, combined with MCP grants.
• Public visibility alone grants no write/review rights. Reuse authorized public contributions; task access follows its own policy.
• Preserve direct edit rights and normal task operations. Submission is explicit; do not silently convert direct writes into proposals or force review of every task action.
• Read-only keys cannot submit. Review requires moderation and publication rights. Authorship alone grants no self-approval.
• Protect text, diffs, history, counts, exports and live events using target access; recheck revocation and privacy restrictions.

Dashboard and MCP

• Unified Moderation queue: project/type/status filters, author, explanation, base/current/proposed diff, conflicts, approve/reject actions.
• Eligible contributors get Suggest changes on readable targets and a pending receipt/link. Preserve drafts during live updates.
• Provide proposal_create/list/get/review/withdraw contracts with public IDs, expected versions, bounded pagination and actionable errors; align final names with existing tools.
• Adapt memory submission/review APIs without breaking clients or duplicating queues/reviews.

Migration and acceptance

• Preserve pending/rejected/approved memory revisions, published pointers and attribution. Map reviews once; no automatic approval or data loss.
• Approved task changes run existing validators: assignment references, statuses, open-child completion constraints, access and implemented blocker rules.
• MSTest/service and HTTP MCP coverage per type: submit/read/approve/reject/withdraw, forbidden roles/grants, stale bases, concurrent reviewers, failed-publication rollback, archived/deleted targets and revoked access.
• Test migration fixtures, legacy clients and pending-content isolation across queries/exports.
• Verify desktop/mobile review, editing, navigation and live updates without lost drafts.
• Deliver implementation, migration/recovery notes, agent guidance and committed tests. Deployment is a separate rollout step.