feat: update Mattermost rendering guidelines for standups and enhance daily logs with recent validation details

project-knowledge/06-daily/2026-05-12.md

@@ -3,13 +3,13 @@ type: daily
 project: fidelity
 date: 2026-05-12
 status: active
-focus: [pdiap-12284, pdiap-15836]
-work-items: [PDIAP-12284, PDIAP-15836]
-blockers: [xflowviewmaker-xflowsdk-dependency-mismatch]
+focus: [pdiap-12284, pdiap-15836, rest-validation]
+work-items: [PDIAP-12284, PDIAP-15836, PDIAP-15838]
+blockers: []
 tags:
   - daily
   - fidelity
-updated: 2026-05-12
+updated: 2026-05-13
 ---
 
 # 2026-05-12
@@ -31,18 +31,21 @@ updated: 2026-05-12
 - Files reported changed: `FlowConfig.swift`, `FlowViewBuilder.swift`, `FlowViewMaker.swift`, and `XFlowManager.swift`.
 - Validation reported: SwiftUI remains the default host mode; explicit UIKit host path preserves dismissal-completion behavior; delegate callbacks/session cleanup still happen after confirmed dismissal; existing `FlowConfig` standard init call sites remain compatible; edited files had no file-level diagnostics.
 - Build validation is not green yet. XFlowViewMaker's module build failed because its podspec currently resolves `XFlowSDK 2.8.48`, which does not expose the new host-mode type/API. XFlowSDK SwiftPM validation in that environment is also blocked by registry configuration: no registry configured for the `fidelity-src` scope.
+- After manual dependency/build handling, the Fid4 compile path is now green for the latest `FlowViewBuilder` shape. The source-level fixes moved setup side effects out of the `@ViewBuilder`, kept `@ViewBuilder` confined to host-view construction, and preserved internal type safety without reintroducing `AnyView`.
+- `PDIAP-12284` was moved to In Progress. `PDIAP-15836` may become a subtask of `PDIAP-12284`; Jeff planned to ask Quy how to handle the Jira structure and story points.
+- David explained that "host-mode resolution" is shorthand for deciding whether XFlow builds through the SwiftUI host path or the temporary UIKit/`UIHostingController` path. XFlowViewMaker makes that decision before calling XFlowSDK; SwiftUI is the default and UIKit is selected only when the flag explicitly enables it.
+- For REST validation, David confirmed Fid4 can be pointed at production through a plist value, which is the preferred non-pushed path. Testing with the production plist still showed GraphQL being used in the tested case. Raj appears to have a production account for follow-up production validation.
 
 ---
 
 ## Next Steps
 
-- Keep the implementation changes if the local diff matches the reported boundaries, then perform a minimal dependency-alignment follow-up so XFlowViewMaker validates against the updated XFlowSDK branch/API instead of pod version `2.8.48`.
-- Separate code-correctness validation from environment/dependency blockers when reporting status.
-- After dependency alignment, rerun the targeted symbol/error/compile pass to confirm no stale enum names, host defaults, or dismissal sequencing regressions remain.
+- Move to runtime validation now that compile is green: first run a representative Fid4/XFlow flow with the default configuration and confirm logs show the SwiftUI host path is selected.
+- Then run a controlled UIKit-host experiment by forcing/simulating `iOS-XflowUIKitHostEnabled == true`, and confirm logs show the UIKit host path while preserving dismissal-completion behavior.
+- Keep the evidence log-based and separate default SwiftUI behavior from the explicit UIKit-flag path.
 
 ---
 
 ## Blockers
 
-- XFlowViewMaker compile validation is currently blocked by dependency mismatch against `XFlowSDK 2.8.48`, not by a confirmed code-level error in the host-mode changes.
-- XFlowSDK SwiftPM validation is blocked in the current environment by missing `fidelity-src` registry configuration.
+- No current source-level compile blocker after manual dependency/build handling. Runtime host-path validation is still pending.

project-knowledge/06-daily/2026-05-13.md

@@ -0,0 +1,49 @@
+---
+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.
+
+---
+
+## 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.
+
+---
+
+## Communication
+
+- Mattermost sync refreshed May 12 context around `PDIAP-12284` / `PDIAP-15836` Jira structure, host-mode wording, and production REST-validation setup.
+
+---
+
+## Next Steps
+
+- Focus today on the combined `PDIAP-12284` / `PDIAP-15836` runtime validation: default SwiftUI host path first, then explicit UIKit-host flag path.
+
+---
+
+## Blockers
+
+- None currently.