docs: add assisted exit transfer and history design documents
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
# Assisted Exit Transfer and History Documentation Plan
|
||||
|
||||
**Status:** Documentation update only. No application or schema implementation is authorized by this record.
|
||||
**Date:** 20 August 2026
|
||||
|
||||
## Deliverables
|
||||
|
||||
1. Amend the existing `AUTH`, `PRJ`, `TSK`, `ATT`, `CAL`, `INT`, `UI`, and `DB` rows without adding requirement IDs.
|
||||
2. Synchronize the explained and very-simple teaching copies.
|
||||
3. Update `UC-04`, `UC-05`, `UC-06`, and `UC-14`, required workflow pages, and regenerate the SRS from its generator.
|
||||
4. Update `PRODUCT.md`, `.agents/PROJECT_PLAN.md`, `AGENTS.md`, and `README.md` with the locked boundary and Iteration 2 ownership.
|
||||
5. Add the append-only requirements update manifest.
|
||||
6. Preserve both DDL files, both Mermaid structures, all mockup/reference assets, and `.DS_Store` byte-for-byte.
|
||||
|
||||
## Validation gates
|
||||
|
||||
- Exactly 260 unique requirement rows in authoritative, explained, simple, and generated SRS catalogues.
|
||||
- Exactly 14 SRS use cases.
|
||||
- Exactly 23 documented tables and 56 named foreign-key relationships; no DDL byte change.
|
||||
- Generated SRS agrees with the canonical requirement rows and updated use cases/workflow pages.
|
||||
- All local Markdown links resolve.
|
||||
- Protected DDL/mockup/reference hashes and `.DS_Store` hash match the pre-update snapshot.
|
||||
- `git diff --check` passes.
|
||||
|
||||
## Non-goals
|
||||
|
||||
No Java, Flyway, SQL, Mermaid structure, mockup, frontend asset, branch, commit, push, or deployment change is part of this task.
|
||||
@@ -0,0 +1,45 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user