[EL-35] Add full family-tree editing, provenance, undo, conflict resolution, and approved writeback

[sodejm]

Catalog ID: EL-35

Public issue: #129

Reviewed baseline: 71abaf4067d4118f28910a22c20524b4e0282b28

Core objective: Implement post-MVP family-tree editing only after #18
establishes approved policy, with field provenance, reversible operations,
conflict resolution, validated output, and explicit writeback approval.

Priority / phase: P3 / Post-MVP editing

Publication status: Published as #129.

Dependency mapping

• Blocks: None
• Depends On: #103, #106, #109, #122, #123, Feature: plan full family-tree editing and writeback workflows #18
• Relates To: #117

UX/UI requirements

• Provide structured person, family, event, relationship, citation, and note
  editing with source context.
• Distinguish unsaved, validated, conflicted, model-suggested, and approved
  states.
• Provide provenance, undo/redo, reviewable diffs, conflict choices,
  validation, and explicit publication.
• Saving a local form never implicitly writes a source GEDCOM/database.

Public interfaces

• Final DTOs and operations must implement policy ratified by Feature: plan full family-tree editing and writeback workflows #18.
• Expected contracts include immutable revisions, edit operations, provenance,
  conflicts, findings, publication previews, and approval tokens.
• No implementation may decide policy that Feature: plan full family-tree editing and writeback workflows #18 leaves unresolved.

Underlying app changes

• Add a transactional edit model separate from immutable source imports.
• Store append-only/reversible edit operations and field-level provenance.
• Add conflict detection, comparison, validation, dry-run publication, and
  atomic artifact creation.
• RootsMagic writeback remains prohibited unless Feature: plan full family-tree editing and writeback workflows #18 explicitly approves a
  separately bounded mechanism.

Acceptance criteria

• Feature: plan full family-tree editing and writeback workflows #18 closes with approved trust, provenance, undo, conflict, validation,
  and writeback decisions before implementation.
• Every edit records source/actor context, time, prior revision, and
  provenance.
• Undo/redo is deterministic after restart.
• Concurrent edits produce conflicts and never silently overwrite.
• Model suggestions require human acceptance into history.
• GEDCOM publication is loss-minimal, optionally rooted, validated,
  non-aliasing, and atomic.
• Interoperability covers GEDCOM 5.5.5, GEDCOM 5.5.1 fallback, Ancestry,
  Geni, and MyHeritage.
• Failure/cancellation/crash cannot corrupt edit storage or sources.

Security mitigations and rejected anti-patterns

• Applies TM-F01, TM-F02, TM-L02, TM-A02, TM-S01, TM-C01, and TM-O01.
• Reject direct source mutation, implicit RootsMagic writeback,
  last-write-wins, model-authoritative edits, hidden conflict resolution,
  complete-file IPC, in-place GEDCOM overwrite, and unaudited destruction.

Workspace mapping

• Exclusive owned paths: desktop/src/features/tree-editor/**,
  src/ancestryllm/api/routes/tree_editor/**,
  src/ancestryllm/services/tree_editor/**,
  tests/services/tree_editor/**, and
  desktop/tests/tree-editor/**.
• Shared-file rule: Policy, migrations, GEDCOM writers, generated
  contracts, dependencies, and lockfiles require coordinator ownership after
  Feature: plan full family-tree editing and writeback workflows #18 approval.
• Base rule: Branch after all dependencies, especially Feature: plan full family-tree editing and writeback workflows #18, are complete.
• Branch: feature/electron-el-35-family-tree-editor
• Worktree: /Users/justinsoderberg/Development/worktrees/ancestryllm-electron-el-35-family-tree-editor
• Validation: make test; make lint; make typecheck; make security;
  pnpm --dir desktop test; pnpm --dir desktop typecheck; GEDCOM
  interoperability and crash recovery

[sodejm]

Recommended Codex configuration

• Planning: gpt-5.6-sol with xhigh reasoning
• Implementation: gpt-5.6-sol with max reasoning
• Rationale: This is release-, sandbox-, plugin-, backup-, architecture-, or writeback-critical work where a subtle error could compromise security, user data, or release integrity; maximum implementation verification is warranted.
• 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.