Repository navigation
设计：PersonaBot / Channel 破坏性删除与 Purge 依赖契约 #138
Description
Goal
Define the explicitly destructive lifecycle for deleting a PersonaBot or Channel without conflating it with the reversible Hidden Channel presentation state.
Human-confirmed decisions (2026-10-06)
- PersonaBot deletion asks whether to also delete Memory files through a checkbox, default unchecked every time. The confirmation provides direct access to the resolved Memory folder, including a one-click native Host folder action.
- Ordinary Channel deletion ends participation and retains history. Content Purge is a separate explicit confirmation.
- ADR-0130 records the lifecycle/dependency matrix and recovery/ledger boundaries in design PR Define explicit Memory erasure and history-preserving deletion #898, awaiting Human QA. Runtime deletion controls and Purge Ledger are not delivered by this design ticket.
Native implementation follow-ups
- Tracer: delete a PersonaBot with explicit optional Memory erasure #896 — PersonaBot deletion with explicit optional Memory erasure, native folder action and durable historical repository locator; blocked by 设计：PersonaBot / Channel 破坏性删除与 Purge 依赖契约 #138.
- Tracer: purge Channel content with a durable restore-safe ledger #897 — history-preserving Channel deletion, separate Content Purge and a real monotonic ledger/checkpoint/union; blocked by 设计：PersonaBot / Channel 破坏性删除与 Purge 依赖契约 #138/Tracer: delete a PersonaBot with explicit optional Memory erasure #896.
- Tracer: export a complete Profile and restore as new with explicit activation #886 — complete-core export/restore-as-new now has native blocking edges to Tracer: delete a PersonaBot with explicit optional Memory erasure #896/Tracer: purge Channel content with a durable restore-safe ledger #897 as well as this design. Do not start it with a placeholder ledger.
Both children use v1.1 and Project V1 · Memory. Each runtime PR requires genuine DSH functional screenshots/recording and Human QA before merge.
Design scope (resolved in ADR-0130, pending PR acceptance)
PersonaBot deletion
- Which PersonaBot identity records, Orchestrator/Assignment Session references, Workspace Grants, adapter bindings, exports, and audit records are retained or purged?
- Is the PersonaBot's managed Memory Repository deleted by default, offered as a separately confirmed Purge Everywhere scope, or retained for recovery?
- What dependency report is shown before confirmation, including copies outside BotHarness control?
Channel deletion
- Does deletion remove Source Event bodies and unshared Attachments from the Messaging authority while retaining the minimal causal/audit tombstone defined by Content Purge?
- How are shared attachments, Inbox/Outbox references, provider-side copies, exports, backups, and Purge Ledger checkpoints handled?
- What differs between a local group Channel and an externally bridged Channel?
Required product boundary
Hidden Channelremains reversible roster presentation state and never enters this destructive path.- Destructive actions require an explicit dependency report and separate confirmation.
- Content Purge and Purge Everywhere keep the canonical meanings defined in
CONTEXT.mdand ADR-0037.
Exit criteria
- One accepted lifecycle and dependency matrix for PersonaBot deletion.
- One accepted lifecycle and dependency matrix for Channel deletion.
- Recovery, audit tombstone, provider-copy, backup, and Memory Repository behavior are explicit.
- Follow-up implementation tickets are vertical, Human-testable tracer bullets rather than horizontal cleanup layers.
No destructive implementation is authorized by this issue alone.
Activity
DoodleBears commentedon Oct 5, 2026
#138 deletion / Purge contract proposal
Status: proposal pending Human decisions; no destructive implementation is authorized.
Verified current implementation
Recommended lifecycle matrix
Purge / restore prerequisite
The first implementation ticket should be a runnable Content Purge slice: dependency preview → separate Human confirmation → durable monotonic ledger entry → Messaging body removal → cold restart and restore union proof. The ledger must be present before Content Purge can claim success; interrupted application must fail closed and converge from that ledger, rather than expose resurrected content.
#886 must depend on that real ticket, not only design acceptance. It exports the creation-time checkpoint, enforces the union with the target ledger before Messaging mounts, and discloses that offline older manual backup files cannot know subsequent purges. Do not serialize a placeholder ledger as if purge protection exists.
Bounded follow-up delivery
Open Human decisions: whether ordinary PersonaBot deletion retains Memory, and whether ordinary Channel deletion retains message bodies. The first proposed choices preserve existing behavior and require explicit destructive confirmation for erasure.
DoodleBears commentedon Oct 5, 2026
Agent work claim
codex/local/01a0f25f-2150-75e3-8895-23d35394b8d8(not a DSH Session)codex/138-deletion-purge-contractAt claim time #138 had no existing agent claim, assignee, child implementation ticket or open implementation PR. Human decisions: deleting a PersonaBot offers explicit optional Memory deletion, initially unchecked, with direct access to the corresponding Memory folder; ordinary Channel deletion retains history and Content Purge is separately confirmed. No real user data deletion will be performed by this design task.
DoodleBears commentedon Oct 5, 2026
Agent work outcome
codex/local/01a0f25f-2150-75e3-8895-23d35394b8d8(not a DSH Session)0df778f9e21944d20dd459bc67306ad71fe16c9bHuman-confirmed scope is recorded in ADR-0129, both product contexts, the living architecture and both documentation Release Ledgers: PersonaBot deletion offers an unchecked optional Memory checkbox and actual native folder access; ordinary Channel deletion retains history and Content Purge is separately confirmed. The matrix explains historical identity/Session attribution, stopped execution and grants, shared-reference limits, provider/export/backup copies, incomplete file cleanup and the real monotonic ledger/checkpoint prerequisite.
#896/#897 are published native sub-issues of #138, both v1.1 / Project V1 · Memory. #897 is blocked by #138/#896. #886 has actual native dependencies on #138/#896/#897. Readback verified these relationships; no design completion or empty checkpoint will be treated as runtime purge protection.
Lint, format, typecheck, release/ADR checks, build, Chinese OG regeneration and the 334-page docs build passed. Independent final-head Standards review: 0 documented violations / judgment findings. Spec review: 0 findings. Full remote CI is running: https://github.com/BotHarness/BotHarness/actions/runs/37351163114 . No runtime behavior changed or data erased; genuine functional E2E UI evidence belongs to #896/#897 implementation, which has not begun.
No merge or sibling implementation begins before explicit Human approval. #138 stays open pending this design PR.
Avoid concurrent deletion ADR number allocation conflict
DoodleBears commentedon Oct 5, 2026
Final design handoff after CI repair
codex/local/01a0f25f-2150-75e3-8895-23d35394b8d8(not a DSH Session)7af9cf568aa58e80298dee05b9540bbc38173162The initial CI failure was a concurrent ADR number allocation: main merged WeChat ADR-0129 after this branch's base. This decision is now ADR-0130; the rename is byte-identical, references in both ledgers/architecture/issue bodies are updated, and lint/format/docs passed again. Final-head independent Standards and Spec reviews both have 0 findings. There is no runtime or data-deletion change.
Final-head full CI is running: https://github.com/BotHarness/BotHarness/actions/runs/37351864298 . It is not reported as passed. #896/#897 remain native children with the previously verified Project/milestone/blocking edges, and #886 waits for their real runtime delivery. No merge or sibling implementation before explicit Human approval.
Define explicit Memory erasure and history-preserving deletion (#898)
DoodleBears commentedon Oct 5, 2026
Agent work outcome
codex/local/01a0f25f-2150-75e3-8895-23d35394b8d8(not a DSH Session)7af9cf568aa58e80298dee05b9540bbc38173162a3506031a5b3a596fdc1372d3ef55f24d8e75a15Full exact-head CI passed: https://github.com/BotHarness/BotHarness/actions/runs/37351864298 . Independent Standards and Spec reviews found 0 findings. CodeRabbit was rate-limited and was not represented as a code review. ADR-0130 is accepted design; runtime deletion/Purge is not claimed delivered. Next authorized implementation is #896, then #897/#886 behind their real dependencies and per-PR Human QA gates.