0.4.0

AncestryLLM 0.4.0

Status: Unreleased development candidate. These notes describe the implemented first slice of the 0.4.0 milestone; they are not a publication or release-readiness claim. Milestone 3 and release tracker #193 are authoritative for scope, current completion, acceptance criteria, and remaining gates.

Implemented boundary slice

• RootsMagic now has declared public core, query, and export boundaries. RootsMagicService composes those concerns instead of owning SQL generation policy itself.
• RootsMagicExporter.map() returns a typed, validated in-memory RootsMagicGedcomDocument without creating output or report files. export() builds on that result and retains rollback-capable pair publication.
• GedcomService consumes the public parser, graph, identity, quality, serialization, and synchronization seams. Exact architecture gateways prevent services and unrelated modules from reaching through to private compatibility kernels.
• Public façade allowlists and representative prohibited-import tests make the dependency direction executable.
• The immutable RootsMagic SQLite source and schema implementations now have physical source.py and schema.py ownership behind the public core façade. Query results include deterministic truncation metadata and tagged JSON-safe binary values, while legacy private import paths remain aliases.

Preserved compatibility and safety

The one-shot CLI and prompt-toolkit/Rich REPL remain the only implemented adapters. Command grammar, stable coded errors, immutable RootsMagic inputs, loss-minimal GEDCOM handling, explicit provider selection and consent, and network-free provider=none behavior are unchanged.

RootsMagic mapping verifies the source fingerprint before and after conversion. Publication still stages the GEDCOM and sanitized report and commits or rolls back the pair as one operation.

Remaining 0.4.0 work

The façade slice does not claim that the historical kernels have been fully decomposed. GEDCOM issues #164 through #166 still require deeper physical extraction from gedcom/engine.py and gedcom/incremental.py, followed by removal of obsolete compatibility paths. The implemented work establishes the supported boundaries that those extractions must preserve.

Before 0.4.0 can be declared release-ready, every scoped issue and acceptance criterion in release tracker #193 must be complete and the canonical local and hosted release gates must pass. Project and lock metadata now identify the 0.4.0 development line; this is not permission to tag or publish it.