reset

Reset Dex for changed answers

If 04-Projects/ does not exist, this vault was never set up. Use setup instead.

If the user actually changed jobs or roles — new employer, new email domain, an old identity to archive — use change-job instead: it runs this same reset and then guides the passes a reset alone never touches (re-sorting people for the new domain, archiving old-role goals, priorities and projects, re-pointing open tasks). A reset by itself is the right lever only for changed preferences or answers within the same working life.

To turn a single room on or off, use manage-capabilities — it is a much smaller change than a full reset and never touches the rest of the profile.

Otherwise:

1. Tell the user what a reset does and does not do, and get an explicit yes before calling anything:

   "I'll walk you through the same questions as first-time setup and rewrite your profile — role, company, pillars, communication style, working week and rooms. Every setting you don't re-answer carries forward unchanged, and nothing you've written is deleted or moved: your notes, people, meetings and projects all stay exactly where they are. Want to go ahead?"

   Stop here if they decline.

2. Call start_onboarding_session(force_new=True) from onboarding-mcp. The force_new flag is what makes this a reset rather than resuming a half-finished setup. Know what it re-arms: the fresh session clears the calendar answer and the harness confirmation, so the flow's calendar step and harness-selection confirmation must both be replayed — finalize_onboarding refuses to run until each has been addressed again. Do not skip past them expecting the old answers to still count.

3. Read .claude/flows/onboarding.md and follow it as the single source of the conversation, exactly as setup does.

4. Before finalizing, call finalize_onboarding(dry_run=True) and show the user what it reports it would create, plus the profile_changes list — every profile setting that will change, old value → new value. Settings not in that list carry forward. Tell the user that on a vault that already completed onboarding, finalizing first takes a snapshot of the current profile, pillars and room choices — before anything is rewritten — so the reset can be checked afterwards and undone if it went wrong. Then call finalize_onboarding().

5. After finalizing, show the user the transition_verification summary from the finalize response — it reads "Changed (you chose): … Carried forward: N settings. Lost: none." Read it before relaying it: if it reports anything lost or changed outside their answers, say so plainly instead of declaring success, and offer restore_transition_capsule — preview first (it defaults to a dry run), then rerun it with dry_run=false if they want the two settings files put back exactly as they were. verify_transition re-runs the same check anytime against the snapshot named in the response.