ENG-2185 Move export settings out of Settings into the Export panel

[trangdoan982]

Stacked on eng-2186 — base is that branch, not main. Merge it first.

Reviewer brief

• Result: the 7 export options are set from a collapsed Export options disclosure at the bottom of the Export dialog's Export tab. The Export tab is gone from Settings. Storage keys, the getExportSettings read path, and export behaviour are untouched, so saved values carry over.
• Review focus: this supersedes eng-2186's b441825e flush in BaseTextPanel. That commit held the pending write in a ref and ran it on unmount, covering navigation away. The registry here is a superset: it also covers BaseNumberPanel and BaseSelectPanel, adds the flush-before-read the Export dialog needs, and commits exactly once — the ref version could fire syncToBlock twice if unmount landed inside the inner 100ms window. eng-2186's separate DiscourseNodeColorSetting flush is untouched.
• Review focus: apps/roam/src/utils/pendingSettingWrites.ts and the useDeferredWrite hook in BlockPropSettingPanels.tsx. BaseNumberPanel and BaseSelectPanel deferred their block-prop write by 100ms and cancelled it on unmount, so change link type → click Export could export the previous value and change → Cancel dropped the edit. Panels now register the pending commit next to the timer, unmount commits instead of cancelling, and the Export dialog flushes before it runs. Debouncing is deliberately kept — committing per keystroke would write to Roam on every event. This touches a component every settings panel uses, so the blast radius is the thing to check; it also fixes the same loss in Settings.
• Review focus: ExportOptions was moved with git mv, so it reads as a rename. The only content changes are the import paths (it is no longer inside settings/) and the component name.
• Risk or follow-up: the in-app Roam pass did not happen — see Verification. The code is type-checked, linted, and confirmed present in the dev bundle, but nobody has clicked the 7 controls in a real graph yet.
• Risk or follow-up: sharing-discourse-graph.md had a screenshot of the options inside the Settings dialog, showing the vertical tab list and the pre-taxonomy tab names. It is removed rather than replaced — the prose already names where the options live, and no fresh capture of the Export dialog exists yet, so a replacement image is worth adding once someone can grab one. The frontmatter close-up further down is a crop of the control itself and stays accurate.

Verification

• pnpm install --frozen-lockfile then pnpm ci:validate from the repo root: exit 0. check-types across 12 packages, 142 tests in 23 files passing.
• 5 new unit tests for the pending-write registry, including self-deregistration mid-flush and a commit that registers follow-up work.
• ESLint on every changed apps/roam file: 0 errors. Export.tsx (40) and BlockPropSettingPanels.tsx (3) report the same warning counts before and after this change (stashed and re-ran to compare), so no new ones. One exhaustive-deps warning this change introduced in Settings.tsx is fixed rather than left.
• Dev bundle rebuilt clean; dist/extension.js contains the new disclosure and posthog event, and no longer contains the discourse-graph-export tab id.
• Not done: the manual Roam pass — setting all 7 options, confirming they persist to the same blocks and survive a reopen, and confirming an export honours a changed option. The Chrome extension driving the dev graph timed out, so this is unverified in a live graph. Settings are read inside the export callbacks in getExportTypes.ts, not at dialog mount, so live edits should apply to the next export, but that reasoning is from the code and has not been exercised.

Scope check

• Ran $scope-check against the ENG ticket and final diff.
• Scope beyond Done When:

Three items:

• BlockPropSettingPanels.tsx write timing, in response to a review finding. Out of the ticket's Done When, but the move is what exposes the race — inside Settings the 100ms window was hard to hit, inside the Export dialog change option → Export is the primary flow. Fixing it in the shared panel was unavoidable; discussed and agreed before implementing.

• The Advanced > Export tab and its advancedExport id are removed from eng-2186's taxonomy, which parked them with the comment Leaves Settings entirely in ENG-2185. The saved "discourse-graph-export" alias in settingsTabs.ts now points at the default tab rather than a tab that no longer renders, which is what satisfies the ticket's "deep links still resolve" clause. (My earlier standalone KNOWN_TAB_IDS fallback is gone — eng-2186's resolveSettingsTabId does the job properly.)

• apps/website/content/roam/guides/sharing-discourse-graph.md said the options live on the Export tab of the configuration, which this change makes wrong.

The posthog initialTabId capture now reports the resolved tab rather than the requested one, so telemetry cannot claim a tab that never opened.

Local delegated full review

• Ran a comprehensive review of the entire final diff in a subagent with a fresh context. Use $dg-delegated-full-review when no other full-review workflow is available.

[linear-code]

ENG-2185

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated
discourse-graph	Skipped		Sep 5, 2026 11:12pm UTC

[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 ↗︎.

[devin-ai-integration]

Devin Review found 1 potential issue.

2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)

[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