Symptom

After completing a local-first flow (e.g. bullet-journal), the what-next chooser redisplayed flows in the same default order — putting “Connect to a Krill server” at the top even though the user just finished a local-first task.

Root cause

FlowEngine discarded the lastCreatedKind when branching to a new flow via ChainTo. On ReturnToChooser, the engine went to Idle without preserving any context from the completed flow chain, so FlowChooser had no signal to use for reordering.

Fix

• Added lastCreatedKind: String? to FlowEngineState.Active, updated by each CreateNode step and carried through ChainTo/branchTo transitions.
• On ReturnToChooser, the engine saves the kind to a dedicated _lastCreatedKind: MutableStateFlow before transitioning to Idle; cleared by cancel().
• FlowChooser accepts lastCreatedKind and sorts the visible list into three groups: other node-creating flows → setup/connect flows → the flow that just ran. The sort falls back to the original order when lastCreatedKind is null.
• WalkthroughHost threads engine.lastCreatedKind through to FlowChooser.

Prevention

• State that needs to survive a ChainTo transition must be explicitly threaded through branchTo. New fields on Active that matter across chain boundaries should default to null and be forwarded in branchTo’s parameter list.
• For chooser-ordering logic that depends on runtime engine state, prefer a stable StateFlow on the engine over adding ad-hoc fields to WalkthroughController (controller handles open/close; engine owns flow-execution state).