FEE-840 Add schema export for Obsidian

[trangdoan982]

https://www.loom.com/share/4510e9ed157a4b3395dc8083aae30770

Another export entry point I forgot to mention:

Summary

• Adds an Export discourse graph schema command and settings entry point
• Users can select node types, relation types, relation triples, and templates to include; the selection panel enforces dependency constraints (selecting a relation triple locks in its source/destination node types and relation type)
• Saves the selection to a dg-schema-<vault>.json file via the Electron native save dialog
• Includes the shared foundation that the import PR builds on: ReactRootModal, useSchemaSelection, SchemaSelectionPanel, SchemaSelectionModalBody, specValidation, and nativeJsonFileDialogs

Test plan

• pnpm --filter @discourse-graphs/obsidian check-types
• Open Export schema modal from command palette
• Open Export schema modal from Settings
• Verify dependency enforcement: selecting a relation triple locks the related node/relation types
• Export to a custom filesystem location via native save dialog
• Verify the saved JSON contains the expected dg-schema-<vault>.json structure

Stack

This is PR 1 of 2. PR 2 (import) will be stacked on this branch.

Made with Cursor

---

[linear-code]

FEE-840

[supabase]

This pull request has been ignored for the connected project zytfjzqyijgagqxrzbmz because there are no changes detected in packages/database/supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
discourse-graph	Skipped		Jun 26, 2026 7:51pm

[graphite-app]

PR size/scope check

This PR is over our review-size guideline.

• Recommended: ~200 lines changed
• Acceptable limit: up to 400 lines when well-scoped/self-contained
• Preferred file count: fewer than 5 files

Please split this into smaller PRs unless there is a clear reason the changes need to land together.

If keeping it as one PR, please add a brief justification covering:

• What single problem this PR solves
• Why the files/changes are coupled

[devin-ai-integration]

Devin Review found 2 potential issues.

[mdroidian]

Hey @trangdoan982 , can you split this before review? This PR is currently trying to cover both export and import groundwork in one PR, and that’s too much scope.

Our guideline is 1 PR = 1 Linear ticket, and each ticket/PR should solve one specific problem. Since this work comes from a feedback ticket, the implementation pieces should be split into separate engineering tickets as children of that feedback ticket, then each PR should map to one of those child tickets.

Suggested split:

• Child ENG ticket 1: define the schema file contract and any truly shared foundation needed by both import/export
• Child ENG ticket 2: add Obsidian schema export
• Child ENG ticket 3: add Obsidian schema import

I’d also like us to be stricter about extraction here. Some pieces look broader than the current export use case needs, especially SchemaSelectionModalBody, the large SchemaSelectionState prop surface, openJsonFromUserLocation, and parseDgSchemaFile. Per our placement heuristic, please co-locate code with its primary usage first, export it only when there is a concrete reuse need, and move it to utils/shared components only once there are multiple real call sites.

For this PR specifically, please either narrow it to one ticket’s worth of work or close/supersede it with smaller PRs. At 1,169 lines across 11 files, it’s well over the 400-line threshold, and the scope makes it hard to review responsibly.