[Roadmap] Capability-first refactor for shared core, App Intents, and CLI

[rudrankriyam]

Context

Foundation Lab currently organizes most behavior around SwiftUI screens, view-local state, and a small number of executors. That works for the app UI, but it breaks down when we want the same functionality to be reusable from:

• SwiftUI views
• App Intents and App Shortcuts
• a CLI
• future automation or agent entry points

The earlier CLI draft and the earlier extra-package proposal showed both the need and the risk clearly:

• shared task logic needs to live outside SwiftUI
• thin adapters are good
• extra runtime packages are overhead until reuse pressure is real

Goal

Refactor the codebase toward a capability-first architecture where each user task has one shared implementation in FoundationLabCore and multiple thin adapters:

• app UI adapter
• App Intents adapter
• CLI adapter

Architectural rules

• The core layer asks: what task is being performed?
• FoundationLabCore owns shared request/result models, use cases, domain models, provider seams, and reusable Foundation Models-backed providers.
• SwiftUI, App Intents, and CLI layers own navigation, presentation, command parsing, dialog handling, and output formatting.
• perform() in App Intents stays thin and never owns business logic.
• CLI commands stay thin and never reimplement feature logic.
• No separate FoundationLabIntelligence or FoundationLabAppIntents package for now.
• Multi-turn chat is explicitly second phase after bounded single-shot capabilities are stable.
• Future runtime or platform changes should land behind provider boundaries rather than leak through the whole app.

Planning assumptions

• As of March 15, 2026, the codebase should align with the currently public App Intents, App Shortcuts, Spotlight, and Apple Intelligence surfaces.
• The shared core should stay reusable enough that later platform changes do not force whole-app rewrites.
• FoundationLabCore/ROADMAP.md is the living in-repo checklist for the remaining extraction work.

Issue stack

1. [Stack 1/9] Create FoundationLabCore package and define dependency rules #110 [Stack 1/9] Create FoundationLabCore package and define dependency rules
2. [Stack 2/9] Create FoundationLabIntelligence package for model and provider adapters #111 closed intentionally: concrete providers remain in FoundationLabCore until a split is justified by real dependency pressure.
3. [Stack 3/9] Extract GenerateBookRecommendation as the first shared capability #112 [Stack 3/9] Extract GenerateBookRecommendation as the first shared capability
4. [Stack 4/9] Add the first task-oriented App Intent backed by GenerateBookRecommendation #113 [Stack 4/9] Add the first task-oriented App Intent backed by GenerateBookRecommendation
5. [Stack 5/9] Add a thin CLI adapter for the first shared capability #114 [Stack 5/9] Add a thin CLI adapter for the first shared capability
6. [Stack 6/9] Extract AnalyzeNutrition as the second shared capability #115 [Stack 6/9] Extract AnalyzeNutrition as the second shared capability
7. [Stack 7/9] Extract first tool capabilities and provider seams for weather and web search #116 [Stack 7/9] Extract first tool capabilities and provider seams for weather and web search
8. [Stack 8/9] Expand task-oriented App Intents with App Entities, shortcuts, and Spotlight foundations #117 [Stack 8/9] Expand task-oriented App Intents with App Entities, shortcuts, and Spotlight foundations
9. [Stack 9/9] Extract shared conversation/session core for multi-turn chat and streaming #118 [Stack 9/9] Extract shared conversation/session core for multi-turn chat and streaming

Execution guidance

• Treat each stack issue as a separate slice of work even if a PR carries adjacent cleanup.
• Do not skip ahead to multi-turn chat before the single-shot capability pattern is proven.
• Preserve current app behavior unless an issue explicitly calls for changing product surface.
• Keep existing navigation intents working until task-oriented intents are clearly ready to replace or coexist with them.