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/06-daily/2026-05-13.md

@@ -0,0 +1,53 @@
+---
+type: daily
+project: fidelity
+date: 2026-05-13
+status: active
+focus: [pdiap-12284, pdiap-15836]
+work-items: [PDIAP-15838, PDIAP-12284, PDIAP-15836]
+blockers: []
+tags:
+  - daily
+  - fidelity
+updated: 2026-05-13
+---
+
+# 2026-05-13
+
+## Focus
+
+- Continue runtime validation for the combined `PDIAP-12284` / `PDIAP-15836` branch.
+
+---
+
+## Work Done
+
+- In yesterday's REST validation meeting, the initial production-environment check showed GraphQL when Fid4 was only pointed at production. The fuller meeting result was that iOS successfully validated REST after Raj enabled the production LaunchDarkly toggle for the specific production test user context, targeting the MID for the account tested with Bruce.
+- Runtime validation for the combined `PDIAP-12284` / `PDIAP-15836` branch now looks good for AccountLink in both host modes. The SwiftUI-default path and forced UIKit-host path both showed consistent host selection and preserved dismissal sequencing, with delegate/session teardown after confirmed dismissal. No AccountLink issue was observed in either host mode during these runs.
+
+---
+
+## Findings
+
+- Do not summarize yesterday's REST validation only as "production still used GraphQL." The accurate framing is that plist-only production environment selection was insufficient, but production LaunchDarkly targeting for the tested user's MID activated REST successfully on iOS.
+- Cleanup/review focus before push: remove temporary `XFlow-DISMISS-DEBUG` prints and consider moving new dismissal-specific helper types out of `XFlowManager.swift` into a dedicated file so `XFlowManager` keeps orchestration responsibilities while dismissal lifecycle state stays isolated.
+- Follow-up SampleApp validation found a likely branch-introduced dismissal regression: SampleApp uses `initialViewController(...)` and presents a UIKit controller path, but the branch defaulted `presentationHostMode` to SwiftUI, so `endActivity` could publish to the SwiftUI dismissal subject even though no `XFlowDismissalHost` subscriber was created. The minimal fix direction is to keep `initialViewController(...)` on the UIKit host/dismiss-completion path while leaving `makeInitialFlowView(...)` on the SwiftUI host path.
+- Updated SampleApp direction: SampleApp should be able to switch between UIKit-host and SwiftUI-host scenarios for validation, while XFlowSDK should infer/use the correct dismissal mechanism from the integration path rather than relying on stale/default host-mode state.
+
+---
+
+## Communication
+
+- Mattermost sync refreshed May 12 context around `PDIAP-12284` / `PDIAP-15836` Jira structure, host-mode wording, and production REST-validation setup.
+
+---
+
+## Next Steps
+
+- Prepare the combined `PDIAP-12284` / `PDIAP-15836` branch for push: clean temporary debug instrumentation, consider extracting dismissal helper types from `XFlowManager.swift`, run a final compile/lint or targeted validation pass, and preserve the AccountLink host-mode validation evidence for the PR/Jira update.
+
+---
+
+## Blockers
+
+- None currently.