Lanes
One lane at a time — the goal, the critical path, and the current wave of blockers.
iOS — Destination editing
CORRECTED 2026-09-22 — THE OLD GOAL IS FALSE. Verified in code. This wave is engineering-complete and waiting on Matthew (t_d997bb65). The old goal read: "Only THREE of 14 destination types actually persist an edit today — website, notes, document. Menu opens a real editor whose save is a no-op stub... The remaining 10 show 'Editing coming soon.'" ALL FOURTEEN KINDS HAVE A REAL EDITOR. ActionEditorRouter.body (apps/ios/.../Features/Destinations/Pages/Components/DestinationEditorRouter.swift) is an EXHAUSTIVE switch over DestinationKind with NO `default:` arm, and its closing comment says so: "All 14 DestinationKind cases are handled above, so the old 'Editing coming soon' branch was unreachable — and while it sat here it made a missing case look survivable. Adding a kind should fail the build here and in isEditableType, not ship a stub." DestinationLaunchpad.handleEditTapped (:990-1007) always opens the router for a saved destination. Its comment records a second bug fixed along the way: gating on `inferredEditActionType` made the Edit button DO NOTHING for action/wifi/payment/bluetooth/form, because that value is nil for all five. THE HISTORY IS THE MOST USEFUL THING IN THIS WAVE, because it is a repeatable bug class and it has now bitten on two platforms. isEditableType used to be a `Set` literal reading `[.document, .website, .notes, .menu]`, and it stayed that way LONG AFTER the other ten editors shipped. The false branch is not a soft fallback — the button relabels to "Edit (coming soon)" and its action becomes an EMPTY CLOSURE. So contact, payment, wifi, bluetooth, link hub, form, action, gallery, video and audio each had a complete, merged, working editor that no user could reach. The fix was to replace the Set with an exhaustive `switch`, so the next kind added to DestinationKind is a COMPILE ERROR rather than a silent stub. ANDROID HAS THE SAME SHAPE AND HAS NOT HAD THE SAME FIX. DestinationLaunchpadViewModel.canEdit() is a 14-term `||` chain and startEdit()'s `when` still carries an `else ->` that reports "coming soon". Both are correct TODAY (verified: enum 14, canEdit 14, startEdit 14, sets identical) but neither can fail to compile when a fifteenth kind lands. Tracked as t_03c63346, and THIS FILE IS THE WORKED EXAMPLE for it. THE THREE COST BANDS IN THE OLD GOAL ARE ALL SPENT: the "already exist, need a router case" group (gallery, video, audio, contact), the "build from scratch" group (payment, link hub, form, wifi, bluetooth, action), and the backend update endpoints those six needed. LinkHubDestinationEdit.swift's header records its own arrival — "Editing coming soon for this type until now, so a link hub was create-only". WHAT REMAINS: t_d997bb65, Matthew's approval gate. Nothing in this wave is code-blocked.