Repository navigation
P5.6: document removal keeps content; who may remove and what 'stops new content' means #195
Description
Phase 5, P5.6 (content on removal). Commits 781ac3b8 (red tests) and b3b63f1f (implementation) on branch p5-removal.
What is built (design decision 4: content kept)
- A removal is a signed
document.removeevent. Its header fieldremovesnames thedocument.putevent ID. It takes no body and carries no tag or document. - Nothing is deleted. The removal event stays in the store. The document, its blob, and its tags are unchanged, and the blob gate is unchanged.
EventStore::documents()setsDocumentRecord::removalwhen the document's own author signed a removal for it. The check runs at read time, so replicas agree whatever the arrival order.
Point chosen: who may remove
- Only the document's author. The document has no group link yet, so a group Admin or Manage cannot be checked. A removal from anyone else is stored and has no effect.
Open points
- Group removal. An Admin or Manage removing a document needs the document-to-group link. That link is not in the model yet.
- "Removal stops new content" is not enforced. Decision 4 does not say which new content is refused, tags on the document or new documents from a removed member. Proposed: a tag on a removed document is void only if its author had seen the removal (causal past). Concurrent tags are kept.
- Conflict with the P5.6 brief. The brief asked for the blob to be refused to every peer after removal, and for a replica to drop its bytes. Decision 4 and task 10 item 4 say keep by default, with hiding only behind an explicit flag. Not built. Owner to confirm keep, or add the explicit hide flag.
Acceptance criteria
- The owner decision on open point 3 is recorded: keep-content-by-default (decision 4 / task 10 item 4) confirmed, or an explicit hide flag is specified and built.
- "Removal stops new content" has a defined meaning: which new content is refused (tags on a removed document and/or new documents), with the causal-past rule for concurrent tags either adopted or replaced, and tests covering it.
- Group removal (Admin/Manage) is either implemented once the document-to-group link exists, or explicitly deferred with the dependency named.
- Behavior for removals signed by non-authors (stored, no effect) remains covered by tests.
Metadata
Metadata
Assignees
Labels
Package/app: id (pkgs/ or apps/ in this repo)Medium: expected under 1 day of workQuestion or design decision to resolveIntake review done: acceptance criteria, links, and normalized labels addedFully doable remotely: design, config, code, cloudOrdinary priority (the default)Queue or user escalation stateHas a queued task in the Supabase agent queueFiled directly by a humanQueue or user escalation stateQueue or user escalation state
Activity
dezren39 commentedon Oct 24, 2026
id train triage (2026-10-24): needs-decision — project owner: document-removal semantics (who may remove, what "stops new content" means); implementation on branch p5-removal.
dezren39 commentedon Oct 27, 2026
Intake review
Phase 5 (P5.6) design issue: the removal event and author-only rule are built on branch p5-removal per the body, but three points were left open — group removal (needs the document-to-group link, not yet in the model), the meaning of 'removal stops new content', and a direct conflict with the P5.6 brief on blob refusal that needs the owner to confirm keep-by-default or specify a hide flag. Still live; point 3 is a decision for Drew/Muse, hence user/review.
Risks: Removal semantics are consensus-visible: replicas must agree on tag validity regardless of arrival order, so the causal-past choice needs tests, not just prose.
Suggested approach: Owner settles point 3 and the 'stops new content' definition on this issue; then a small implementation pass adds the causal-past tag rule with arrival-order tests.
Related: Phase 5 siblings in this repo (P5.x issues, Oct 12 batch); implementation commits 781ac3b/b3b63f1f on branch p5-removal per the body.
Enriched by the fleet monitor (intake pass): labels normalized and acceptance criteria appended to the body. This is triage only — no work has been started.
dezren39 commentedon Nov 1, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 1, 2026
🤖 Agent note · escalated / blocked
pkgs/id/src/event_store/documents.rs:36-82;claims.rs:20-76folds applied tags without a removal check.ChainExthas an optional group field (chain.rs:97-117), but document projection and removal authorization do not use it. Existingtests/content_removal.rs:232-354covers non-author and ordering and uses a mock blob graph; the production blob reference index is not wired (blob_gate.rs:19-21,110-118). No tests run in this triage.