Add daily logs and templates for project fidelity

- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps.
- Established a daily logs index for easy navigation of daily notes.
- Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams.
- Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.

workspaces/fidelity/project-knowledge/02-work-items/pdiap-14859.md

@@ -0,0 +1,67 @@
+---
+type: work-item
+project: fidelity
+status: done
+ticket: PDIAP-14859
+title: "Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation"
+systems: [xflowsdk, xflowviewmaker, fid4, ftframeworks]
+workstreams: [xflow-swiftui-migration, consumer-integration]
+people: [jeff-dewitte, quy-mai]
+related: [pdiap-15836]
+updated: 2026-04-20
+tags:
+  - work-item
+  - fidelity
+  - xflow
+  - swiftui
+---
+# PDIAP-14859 - Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation
+
+## Status
+
+- Done
+- Rollout draft prepared and sent to Jeff for review on April 13, 2026
+- Rollout document was approved, published, and the spike was later moved to Done
+
+---
+
+## Current Framing
+
+- Approved title: `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
+- This work is currently framed in the workspace as a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
+- The process-oriented deliverable has been completed and the spike is closed.
+
+---
+
+## Current Scope
+
+- Define a consumer-facing rollout plan for the broader UIKit-removal work.
+- Preserve both UIKit and SwiftUI paths appropriately while introducing the new path safely.
+- Cover risky entry points such as `FTTransfer`, while keeping the latest spike finding explicit that consumer-side changes there may no longer be strictly required after the SwiftUI dismissal behavior is applied correctly.
+- Include validation expectations in `XQ1`.
+- Use a global feature-flag rollout model rather than entry-point-based enablement.
+- Include consumer communication expectations.
+- Include a 30-day production period with no reported bugs before final removal.
+- Include a follow-up release to remove the feature flag and old code after rollout confidence is achieved.
+
+---
+
+## Notes
+
+- The feature-flag and rollout planning guidance applies to the broader UIKit-removal spike, not only to dismissal-sequencing work.
+- Jeff suggested sending the process-oriented rollout document to Quy for feedback when ready.
+- The draft shared with Jeff already reflects the global feature flag, broad `XQ1` validation, and consumer-facing rollout flow guidance.
+- Additional review feedback from April 13: rename the proposed flag to `xflow-swiftui-enabled`, make consumer contact and `XQ1` validation explicit in the first phase, remove overly technical rollout wording, and avoid implying there are no consumer-side changes without qualification.
+- On April 14, Jeff asked whether the FTTransfer part of the rollout document also needed updating; David confirmed the document had already been revised to clarify that root-cause section.
+- April 15 clarification: do not reuse the existing SwiftUI LaunchDarkly flag for this rollout.
+- The new flag name for this work should be `xflow-swiftui-container-enabled`.
+- The document should note that the flag is `to be added in the future as part of implementation`.
+- Late April 14 guidance: the document was approved late in the day; the next step is to publish it, then close out the spike by commenting `Spike Results:` with the relevant document links and the new follow-up story link.
+- The new follow-up story should also be marked as a blocker for the reopened UIKit-removal story.
+
+---
+
+## Related Work
+
+- Related consumer rollout thinking should stay aligned with `PDIAP-15836`.
+- `PDIAP-15838` should not be framed as part of this UIKit-removal spike.