Objective
Ship and prove a reusable peer-extension platform over the published gf-api while keeping GraphForge Core extension-agnostic.
Workstreams
Acceptance criteria
- Every extension depends only on published public GraphForge APIs; Core never depends on an extension and remains buildable when extensions are deleted.
- Boundary and deletion checks enforce the dependency direction.
- Applicable Rust, Python, and Node packages pass fresh-build or clean-install acceptance.
- Documentation provides a working third-party extension path.
- Each native workstream and its children satisfy their own outcome-based acceptance criteria.
Non-goals
- Adding MCP, HTTP, authentication, authorization, or server lifecycle to Core.
- Distributed consensus, network-mounted project directories, or multiple storage authorities.
- Blocking v0.5.0 publication on post-release extension work.
- Building an extension marketplace or UI.
Relationships
Objective
Ship and prove a reusable peer-extension platform over the published
gf-apiwhile keeping GraphForge Core extension-agnostic.Workstreams
epic: datasets as the first peer extension (gf-datasets) — v0.5.x #20 — dataset infrastructure, reference content, packaging, and author template.
feat(extension): ship local-first genealogy interoperability for GEDCOM 7 and GEDCOM X JSON #21 — local-first genealogy interoperability as a reference domain extension.
extension: publish a queued GraphForge authority artifact #215 — optional queued-authority MCP/HTTP transport as a peer extension.
research(extensions): investigate browser client and XYG integration with native GraphForge #1200 — investigate browser-client versus XYG-adapter ownership for native GraphForge results; closes on an evidence-backed recommendation, not package implementation.
feat(extensions): evaluate and deliver optional decision-model adapters #1574 — optional decision-model evaluation and adapters over M12 public contracts; post-release, with no Core vendor dependency.
Acceptance criteria
Non-goals
Relationships