3.7 KiB
Assisted Exit Transfer and History Design
Status: Approved documentation baseline; application implementation remains Iteration 2 work.
Date: 20 August 2026
Authority: Current primary-implementor decision, applied through existing requirement IDs.
Purpose
Define a safe, understandable way to prepare a member's requested Project exit and expose useful retained history without changing the approved database structure.
Assisted pending exit
A pending request keeps membership, existing assignments, and existing Task rights active. The target cannot receive a newly created/reassigned Task or create a self-Task. Every authorized Project viewer sees one readiness state: replacement Leader required, unfinished Task count, or ready for Mentor decision.
When the target is Leader, the owning Mentor appoints the replacement first. The current/new Leader then uses a right-side drawer to select multiple unfinished TODO, IN_PROGRESS, or BLOCKED Tasks and one eligible active current member. One confirmation commits one immediate all-or-none batch. The Leader repeats until no unfinished Tasks remain.
Cancellation or rejection restores the target's new-assignment eligibility but does not undo completed transfer batches. Approval is allowed only when the target is no longer Leader and owns zero unfinished Tasks; request approval and membership closure then commit atomically.
Direct Mentor removal
Direct removal remains the existing atomic shortcut. An ordinary member's unfinished Tasks transfer to the current Leader. Removing the current Leader requires a replacement and transfers unfinished Tasks to that replacement. Completed Tasks never move and continue to display the removed Intern's retained name.
History views
One Project History tab reads retained feature-owned records for memberships, leadership, invitations, exit decisions, completed and soft-deleted Tasks, comments, work logs, and stored attribution. Admin sees all Projects read-only; the owning Mentor and current members see authorized open Projects; removed members regain read-only Project history only after completion.
Task history shows creator, current/final assignee, status/dates, comment/work-log authors, and deletion attribution. It does not claim previous-assignee or edit/status-event timelines that the schema does not store.
Admin-only read-only History tabs cover Attendance Policy, Calendar, SMTP, and HolidayAPI. They show user-meaningful non-secret metadata and never expose tokens, ciphertext/nonces, passwords, API keys, master-key material, bootstrap state, or internal retry records.
Persistence boundary
No table, foreign key, DDL statement, or Mermaid entity changes. The existing 23 tables and 56 foreign keys already retain the required domain records. GOV-009 remains authoritative: no generic audit/event-sourcing or Task-assignment-history table.
Iteration ownership
work/tasks: pending-target assignment exclusion, atomic batch transfer, direct-removal transfer helper, unfinished count, and retained Task projection.work/projects: exit readiness, Leader replacement order, approval guard/closure, direct-removal orchestration, and Project-history authorization.work/attendance: policy/calendar retained-history queries.work/platform: non-secret SMTP/HolidayAPI revision-history queries.work/reports-ui: persistent warning, transfer drawer, Project History, and Admin-setting History tabs.
Acceptance focus
Tests must cover replacement-before-transfer, a newly joined eligible recipient, pending-target exclusion, repeatable batches, cancel/reject without rollback, zero-unfinished approval guard, direct-removal atomic transfer, completed-name retention, every history role boundary, and secret redaction.