[EL-25] Build encrypted research-person workspace management

[sodejm]

Catalog ID: EL-25

Public issue: #122

Reviewed baseline: 71abaf4067d4118f28910a22c20524b4e0282b28

Core objective: Provide a desktop workspace for creating, reviewing,
updating, and archiving research-person records with provenance, validation,
and encrypted local persistence.

Priority / phase: P1 / Existing-module desktop parity

Publication status: Published as #122.

Dependency mapping

• Blocks: #129
• Depends On: #11, #106, #109
• Relates To: Improvement: add SQLCipher and keyring first-run diagnostics #13, Feature: plan full family-tree editing and writeback workflows #18

UX/UI requirements

• Provide searchable person cards, structured editing, provenance fields,
  unsaved-change protection, duplicate warnings, and accessible archival
  confirmation.
• Separate asserted facts, hypotheses, citations, and model suggestions.
• Mask sensitive living-person fields in list views and notifications.

Public interfaces

• Add ResearchPersonSummary, ResearchPersonRecord, EvidenceReference,
  ProvenanceEntry, and optimistic-concurrency revisions.
• Require explicit create, update, archive, and restore operations with schema
  validation and coded conflicts.
• Never return database keys, encryption material, or unrestricted paths.

Underlying app changes

• Add encrypted persistence and migrations for research-person records.
• Add revision checks, audit metadata, archival semantics, and conflict-safe
  updates.
• Keep research records independent from GEDCOM or RootsMagic mutation.

Acceptance criteria

• Users can create, inspect, update, archive, and restore a record.
• All sensitive persisted fields are encrypted at rest.
• Concurrent edits fail with a revision conflict and recoverable
  comparison UX.
• Every factual field can carry source and provenance metadata.
• Model suggestions remain distinct from accepted facts.
• Living-person data is excluded from notifications, logs, telemetry, and
  crash breadcrumbs.
• Migration, rollback, backup, and corruption tests cover the schema.
• Keyboard and screen-reader flows cover editing, validation, conflict,
  and archive confirmation.

Security mitigations and rejected anti-patterns

• Applies TM-L02, TM-S01, TM-C01, TM-O01, and TM-F02.
• Reject plaintext JSON persistence, browser storage, secrets in records,
  silent last-write-wins, payload logging, automatic source writeback, and
  treating LLM claims as authoritative.

Workspace mapping

• Exclusive owned paths: desktop/src/features/research-people/**,
  src/ancestryllm/api/routes/research_people/**,
  src/ancestryllm/services/research_people/**,
  tests/services/research_people/**, and
  desktop/tests/research-people/**.
• Shared-file rule: Database migration registry, generated contracts,
  navigation, and lockfile changes require a coordinator request.
• Base rule: Branch from updated main after all dependencies merge.
• Branch: feature/electron-el-25-research-person-workspace
• Worktree: /Users/justinsoderberg/Development/worktrees/ancestryllm-electron-el-25-research-person-workspace
• Validation: make test; make lint; make typecheck; make security;
  pnpm --dir desktop test; pnpm --dir desktop typecheck

[sodejm]

Recommended Codex configuration

• Planning: gpt-5.6-sol with high reasoning
• Implementation: gpt-5.6-sol with xhigh reasoning
• Rationale: This issue includes security, privacy, concurrency, provider-boundary, or genealogy data-integrity concerns that require deeper implementation reasoning and verification.
• Delivery: Use test-case-driven development: translate the acceptance criteria into failing or characterization tests first, implement incrementally, then run the applicable tests, lint, typecheck, security, integration, and hosted gates.