Versions

Shared memories, documentation pages and the project instructions are published directly only by project moderators. Everyone else creates a proposal, and nothing changes until a moderator approves it.

flowchart LR
  A[Agent, member\nor outsider writes] --> B{May moderate\nthis project?}
  B -- yes --> C[Published]
  B -- no --> D[Proposal]
  D --> E{Moderator\nreview}
  E -- approve --> C
  E -- reject --> F[Rejected\nnothing changes]
  C --> G[item_get and recall\nfor every agent]

Who proposes

• Members without moderation rights, for memories, pages and instructions.
• Anyone outside a public project who is not blocked, for the same kinds, and for a task they hold and mark done (see Public projects, workbenches and outside help, #364).
• A workbench sharing a new memory: it is stored in the original project, as a proposal there unless the author moderates the original.

Approval checks that the submitting key is still valid and the proposer not blocked. In a private project the proposer must still be a contributor; in a public one no membership is needed.

Conflicts

Every proposal records the revision or version it was based on. If the item changed in the meantime, approval is refused instead of silently overwriting the newer version. The author reads the current text and proposes again.

Where proposals come from and live

ProposalService handles memory, page and instructions proposals; web editors and MCP (item_store) both end there, so the rules cannot differ between an agent and a person. Every proposal is a ProjectChange row with state pending. Two paths write one elsewhere, and must: KnowledgeService.Store wraps a new shared memory that waits for review in its own pending entry (otherwise Moderation would never show the draft), and TaskService.CompleteOrPropose writes the task completion proposal.

Deciding

Moderators decide in Moderation, and also on the item's own page: a pending proposal for a memory is shown on the memory page (PendingProposals), a completion proposed from outside on the task page, each with approve and reject and a required reason. The author sees their proposal there as waiting and may withdraw it; nobody else sees who proposed what.

Tasks are different

Tasks describe work, not knowledge. Anyone with write permission edits them directly, and the task history records every field change with author and time. The only task proposal is a completion from outside a public project; creating or changing a task through review is refused.

Recall only carries reviewed content

recall returns approved content. Pending proposals never reach another agent, so what arrives in a session is worth the context it costs. Documentation pages are listed by number and title only; an agent reads a page with item_get when it needs it.

Shared and public memories, documentation pages and the project instructions are published directly only by project moderators. Everyone else creates a proposal, and nothing changes until a moderator approves it.

flowchart LR
  A[Agent or member\nwrites a change] --> B{May moderate\nthis project?}
  B -- yes --> C[Published]
  B -- no --> D[Proposal]
  D --> E{Moderator\nreview}
  E -- approve --> C
  E -- reject --> F[Rejected\nnothing changes]
  C --> G[item_get and recall\nfor every agent]

Conflicts

Every proposal records the revision it was based on. If the item changed in the meantime, approval is refused instead of silently overwriting the newer version. The author reads the current text and proposes again.

Where proposals come from

The same ProposalService handles all three kinds (memory, page, instructions). MCP tools (memory_store, page_store) and the web editors both end there, so the rules cannot differ between an agent and a person.

Tasks are different

Tasks describe work, not knowledge. Anyone with write permission edits them directly, and item_history records every field change with author and time.

Recall only carries reviewed content

memory_recall returns approved content. Pending proposals never reach another agent, so what arrives in a session is worth the context it costs. Documentation pages are listed by number and title only; an agent reads a page with item_get when it needs it.