[2026-10-20] eagle: work/projects/vscode-migration/postmortem.md

work/projects/vscode-migration/postmortem.md

@@ -47,11 +47,13 @@ The SPM build-time gains in the project description (−24% to −30% clean buil
   - *Prevention:* poll the team before scoping a tooling project that depends on adoption.
 - **The goal was framed around one IDE.** The structural work was easier to accept on its own merits than as "steps to VSCode". Reviewers said these improvements "should have been discussed and prioritized for their own benefits".
   - *Prevention:* scope structural cleanups as their own projects and keep tooling goals separate.
-- **The big TD came after most of the work.** The SPM package design was written after the 2026-10-06 Apple Weekly status update, when most prerequisites had already landed.
-  - *Prevention:* write the TD for the end state before starting the steps.
+- **The approval aged.** The original design was approved in Oct 2025. By the time the prerequisites landed a year later, the context had changed (Cursor licenses dropped, Xcode 27 builds package resources natively). The follow-up design was then reviewed as a new decision and rejected.
+  - *Prevention:* on a long project, re-confirm the plan with the team when the context shifts, before starting the final step.
 
 ## Discussions
 
+**[Convert all macOS modules to Swift Package](https://app.asana.com/1/137249556945/project/1200194497630846/task/1211573210737831) (Oct 2025 – Mar 2026) and its [TD](https://app.asana.com/1/137249556945/project/1202406491309510/task/1211728521308688) — approved 2025-10-24.** The plan: the app code becomes a static library linked by the Xcode app targets, plus a dylib and a launcher app for VSCode debugging only. Brindy asked whether it adds overhead for people who don't use VSCode (no, SPM picks up files automatically) and why iOS wasn't covered. Fernando worried about different linking in Debug and Release (no: Xcode builds keep static linking; the dylib is only used for VSCode). Dominik flagged the missing DBP/NetP support as a blocker; that turned out to apply only to the VSCode setup, so he approved ("this is looking great to me"). The blocker was files shared between targets and the `SPARKLE`/`APPSTORE`/`ALPHA` flags. Removing them became the project's main work: Bitwarden, CrashReporting and AppUpdater moved to local packages, and shared files were moved out of the app and test targets.
+
 **Project thread (Sep 29 – Oct 16).** Juan and Jorge asked how many people use VSCode, and whether the risk was worth it. Jorge and Brindy worried about the CoreData migration. Brindy asked for test evidence on every supported macOS ("you need 110% confidence"), and Pete suggested a survey. Outcome: CoreData migration cancelled (not needed with Xcode 27), benefits and build timings added to the description.
 
 **[TD: Build the macOS browser code as a Swift package](https://app.asana.com/1/137249556945/project/1202406491309510/task/1219304032604521) (Oct 8–15) — won't do.**
@@ -87,6 +89,9 @@ The SPM build-time gains in the project description (−24% to −30% clean buil
 | 2025-03-27 | Project task created |
 | 2025-04-14 | "Testing supported macOS versions" expectation created |
 | 2025-05-27 | Project started |
+| 2025-10-07 | "Convert all macOS modules to Swift Package" step started |
+| 2025-10-24 | TD: convert all macOS modules to Swift Package approved |
+| 2026-03-06 | Module conversion step done (Bitwarden, CrashReporting, AppUpdater packages; shared files moved) |
 | 2026-07-16 | Storyboard-drop subtasks created |
 | 2026-09-29 | Team questions value and risk on the project task |
 | 2026-10-01 | PasswordManager.storyboard dropped |