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

.agents/rules/status-reporting.md

@@ -22,4 +22,5 @@ Use this skill for standups, daily scrum updates, end-of-day summaries, and shor
 - Use explicit work-item ID and title when available.
 - Keep the report concise and ready to send.
 - Do not mention internal evidence sources unless the user asks.
+- For Mattermost-ready standups, include a visible blank line before section headers such as `Today:` and `Blockers:`. Always verify there is an empty line immediately above `Today:` before returning the draft.
 - Use `Blockers: None` only when no blocker is visible in current memory.

.agents/workflows/standup.md

@@ -140,4 +140,5 @@ Return a standup that is:
 - uses `JIRA-ID - Title` or `JIRA-ID Title` formatting instead of comma-separated ID/title formatting
 - preserves chronological order within each Jira item's sub-bullets
 - omits future-sprint stories from `Today` unless they are real blockers
+- includes a visible blank line before `Today:` and before `Blockers:` when present; before returning, verify there is an empty line immediately above each section header so Mattermost renders it correctly
 - is ready to copy/paste into Mattermost as Markdown

agent-memory/workflows/ai-to-ai-prompting.md

@@ -1,7 +1,7 @@
 ---
 type: agent-workflow
 status: active
-updated: 2026-05-06
+updated: 2026-05-12
 tags:
   - process
   - ai-prompting
@@ -61,6 +61,7 @@ Use this structure by default:
 - For VS Code multi-root Copilot workflows, preserve repo-provided customizations such as `.github/prompts`, `.github/instructions`, `.github/agents`, `.github/skills`, and `AGENTS.md`. Shared `fidelity-ai-copilot` customizations should supplement these repo files, while repo-specific instructions should be treated as the practical authority when they conflict.
 - For Fidelity Jira/Confluence access from GitHub Copilot CLI or VS Code, do not assume the approved access method. First have the target AI read the current Fidelity-provided human instructions from Confluence or local exported docs, then configure the smallest matching workflow. If those instructions require terminal `curl` with environment variables such as `COPILOT_JIRA_URL` and `COPILOT_JIRA_TOKEN`, enforce that path; otherwise follow the documented Fidelity-approved method. Never print, persist, or hardcode tokens.
 - Treat `fidelity-ai-copilot` as a self-improving AI harness rather than a static prompt dump: the target AI should notice recurring useful workflows, newly discovered internal instructions, and tool changes, then propose small auditable updates to instructions, skills, prompts, agents, specs, or validation checklists. It should ask before making broad changes and keep product repos clean.
+- When the user says they will handle dependency alignment, registry configuration, or compile/test execution manually on the development machine, generated Copilot follow-ups should not ask Copilot to solve those dependency/tooling issues or run broad builds. Instead, ask Copilot for the smallest source-level fix for the specific compiler error the user provides, state that the user will rerun validation manually, and request a concise summary of changed files and expected validation impact.
 
 ---
 

project-knowledge/01-current/current-work.md

@@ -2,7 +2,7 @@
 type: current
 project: fidelity
 status: active
-updated: 2026-05-12
+updated: 2026-05-13
 tags:
   - current-work
   - fidelity
@@ -24,6 +24,8 @@ tags:
 - Keep host-mode resolution decoupled from XFlowSDK and app-specific LaunchDarkly/Flagship clients; XFlowSDK should consume a resolved host-mode decision, while Copilot/code inspection should confirm whether XFlowViewMaker can use existing `FeatureEnabling` / `Featuring` abstractions or needs a small dependency-injection path.
 - May 12 implementation pass for `PDIAP-12284` / `PDIAP-15836` indicates the host-mode API is branch-local/new, keeps two enum types to preserve the XFlowViewMaker/XFlowSDK boundary, uses neutral `swiftUIHost` / `uiKitHost` cases, sets the feature flag key to `iOS-XflowUIKitHostEnabled`, defaults missing/false/unavailable values to SwiftUI, and removes `AnyView` from `buildFlow` internals while leaving it only at the existing public `FlowViewMaker` boundary.
 - Current compile validation blocker for that branch appears to be dependency alignment: XFlowViewMaker's podspec resolves `XFlowSDK 2.8.48`, which does not expose the new host-mode API; XFlowSDK SwiftPM validation is also blocked in the current environment by missing `fidelity-src` registry configuration.
+- After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime log evidence: confirm a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to confirm the temporary UIKit host path and dismissal-completion behavior.
+- `PDIAP-12284` moved to In Progress on May 12. `PDIAP-15836` may become a subtask of `PDIAP-12284`; final Jira structure and point handling are pending Quy/Jeff direction.
 - Latest `PDIAP-12284` / `PDIAP-15836` simulator log review suggests the SwiftUI-host dismissal sequence is firing in the intended order for the tested run: host disappearance is confirmed before `fireEndActivityDelegates`, delegate callbacks, and `activitySession` cleanup. Treat this as a promising validation run, not final story closure.
 - Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
 - Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
@@ -52,6 +54,7 @@ tags:
 - Jeff confirmed May 11 that the REST back end has now been deployed, and a validation meeting is scheduled for May 12 with the team lead and Bruce. They will toggle the REST flag during the meeting and test both states. Jeff asked David to smoke-test Fid4 `4.32` non-REST flows ahead of the meeting.
 - REST detection for the meeting: use Charles Proxy to check `/xflow/api` endpoints and inspect `mobile.launchdarkly.com` bulk payloads for the raw evaluated flag value.
 - Production testing: Raj is trying to get approval to test in production, or they may flip the toggle directly in production. A production test account will be needed; currently only Bruce is known to have one. David found a way to force the production environment from the simulator if needed.
+- May 12 REST validation nuance: pointing Fid4 at production through the plist by itself still showed GraphQL, but the fuller meeting result was successful iOS REST validation after Raj enabled the production LaunchDarkly toggle with specific targeting for the production test user's context, specifically the MID for the account tested with Bruce. The accurate framing is not simply "production still used GraphQL"; the key difference was production LD targeting for the specific user context.
 - Jeff confirmed the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) is in scope for the current `PDIAP-12284` / `PDIAP-15836` branch and asked David to implement it there.
 - `PDIAP-15838` draft PR has reached external review; Bruce left minor feedback, David addressed it, and Jeff directed David to move the ticket to Done while holding the merge
 - Do not merge the GraphQL/Apollo removal PR until REST backend is live in production and the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for at least 30 days without issues

project-knowledge/01-current/work-items.md

@@ -2,7 +2,7 @@
 type: current-work-items
 project: fidelity
 status: active
-updated: 2026-05-12
+updated: 2026-05-13
 tags:
   - current-work
   - work-item
@@ -20,7 +20,7 @@ Update the per-ticket files first when scope, status, sequencing, or communicati
 
 - `PDIAP-15838` - Remove Apollo for iOS
   Detail: `project-knowledge/02-work-items/pdiap-15838.md`
-  Current note: ticket moved to Done after external review feedback was addressed, but the draft PR stays unmerged. Keep the branch up to date with `main` until REST backend is live in production and REST toggles have been enabled for consumers for the required validation window; expected merge timing is at least 30 days out. The REST back end has now been deployed, and a validation meeting with the team lead and Bruce is set for May 12.
+  Current note: ticket moved to Done after external review feedback was addressed, but the draft PR stays unmerged. Keep the branch up to date with `main` until REST backend is live in production and REST toggles have been enabled for consumers for the required validation window; expected merge timing is at least 30 days out. May 13 follow-up validation succeeded on iOS after Raj enabled the production LaunchDarkly toggle for the specific production test user's MID.
 
 - `PDIAP-15836` - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment
   Detail: `project-knowledge/02-work-items/pdiap-15836.md`
@@ -28,7 +28,7 @@ Update the per-ticket files first when scope, status, sequencing, or communicati
 
 - `PDIAP-12284` - Remove UIKit wrapping from XFlow
   Detail: `project-knowledge/02-work-items/pdiap-12284.md`
-  Current note: reopened after rollback and should be handled with `PDIAP-15836` in the same branch. Current implementation direction is to avoid Fid4 per-flow host-mode mapping and instead evaluate XFlowViewMaker-owned global host-mode resolution, with SwiftUI as default and `UIHostingController` only as an explicit temporary fallback. May 12 implementation pass resolved earlier shape concerns with neutral enum names, `iOS-XflowUIKitHostEnabled`, SwiftUI default semantics, and `AnyView` removed from builder internals. Remaining validation blocker appears to be dependency alignment: XFlowViewMaker is resolving `XFlowSDK 2.8.48`, which lacks the new host-mode API.
+  Current note: moved to In Progress on May 12 and should be handled with `PDIAP-15836` in the same branch. Current implementation direction is to avoid Fid4 per-flow host-mode mapping and instead evaluate XFlowViewMaker-owned global host-mode resolution, with SwiftUI as default and `UIHostingController` only as an explicit temporary fallback. May 12 implementation pass resolved earlier shape concerns with neutral enum names, `iOS-XflowUIKitHostEnabled`, SwiftUI default semantics, and `AnyView` removed from builder internals. Fid4 now compiles after manual dependency/build handling; next validation is runtime log evidence for default SwiftUI host first, then forced UIKit-host flag behavior. `PDIAP-15836` may become a subtask pending final Jira/points direction.
 
 ## Backlog / Future Reference
 

project-knowledge/02-work-items/pdiap-12284.md

@@ -1,14 +1,14 @@
 ---
 type: work-item
 project: fidelity
-status: backlog-ready
+status: in-progress
 ticket: PDIAP-12284
 title: "Remove UIKit wrapping from XFlow"
 systems: [xflowsdk, xflowviewmaker]
 workstreams: [xflow-swiftui-migration, consumer-integration]
 people: [jeff-dewitte]
 related: [pdiap-15836, pdiap-15838]
-updated: 2026-05-12
+updated: 2026-05-13
 tags:
   - work-item
   - fidelity
@@ -20,14 +20,15 @@ tags:
 
 ## Status
 
-- Reopened after rollback.
+- Reopened after rollback and moved to In Progress on May 12.
-- Quy already moved this story into the next sprint (`26Q2.6`); leave it in To Do until the sprint starts on Thursday.
 - Jeff directed David to do this UIKit-removal work and `PDIAP-15836` dismissal/lifecycle work in the same branch because both are disruptive enough to require consumer testing.
 - Current implementation direction is to avoid Fid4-owned per-flow host-mode mapping and evaluate XFlowViewMaker-owned global host-mode resolution.
 - David continued the implementation/validation loop on May 11; current simulator log review is promising for the SwiftUI-host dismissal sequencing in the tested run.
 - Jeff confirmed on May 11 that the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) should be implemented as part of this branch's work.
 - May 12 implementation pass resolved several earlier concerns: host-mode API appears branch-local/new, enum cases were renamed to neutral `swiftUIHost` / `uiKitHost`, the final flag key is `iOS-XflowUIKitHostEnabled`, missing/false/unavailable flag values default to SwiftUI, and `AnyView` was removed from `buildFlow` internals while remaining only at the existing public `FlowViewMaker` boundary.
 - Current validation blocker appears to be dependency alignment rather than host-mode code correctness: XFlowViewMaker is resolving `XFlowSDK 2.8.48` from its podspec, which does not expose the new host-mode API needed by the branch.
+- After manual dependency/build handling, Fid4 now compiles with the latest `FlowViewBuilder` shape. Next validation should be runtime evidence: first verify a representative flow selects the default SwiftUI host path, then simulate/force `iOS-XflowUIKitHostEnabled == true` to verify the temporary UIKit host path and dismissal behavior.
+- `PDIAP-15836` may become a subtask of this story; final Jira structure and point handling are pending Quy/Jeff direction.
 
 ---
 

project-knowledge/02-work-items/pdiap-15838.md

@@ -8,7 +8,7 @@ systems: [xflowsdk]
 workstreams: [rest-migration]
 people: [jeff-dewitte, bruce-meeks, adam-abdelhadi, tauf, jeffrey-oleary, aylwing-olivas]
 related: [launchdarkly, github-copilot]
-updated: 2026-05-12
+updated: 2026-05-13
 tags:
   - work-item
   - fidelity
@@ -92,6 +92,7 @@ tags:
 - Jeff confirmed May 11 that the REST back end has now been deployed, and a meeting is scheduled for May 12 with the team lead and Bruce to toggle the flag and test both REST and non-REST states.
 - REST detection for the meeting: Charles Proxy to verify `/xflow/api` endpoints and inspect `mobile.launchdarkly.com` bulk payloads for the raw evaluated flag value.
 - Production testing: Raj is trying to get approval to test in production. A production test account will be needed; currently only Bruce is known to have one. David found a way to force the production environment from the simulator if needed.
+- May 12 REST validation nuance: pointing Fid4 at production through the plist by itself still showed GraphQL, but the fuller meeting result was successful iOS REST validation after Raj enabled the production LaunchDarkly toggle with specific targeting for the production test user's context, specifically the MID for the account tested with Bruce. Treat this as evidence that the production REST path can activate on iOS when the LD targeting context matches.
 
 ---
 

project-knowledge/03-context/process/communication.md

@@ -43,6 +43,7 @@ When the format fits, prefer:
 - On Mondays, use Friday's work context unless a later prior day has Mattermost activity.
 - If the previous calendar day has no project activity because of weekend, holiday, or OOO, use the latest prior day with Mattermost activity.
 - For standups, when a Jira item has multiple concrete updates, use one top-level `JIRA-ID - Title` bullet and indented markdown sub-bullets instead of repeating the same Jira line.
+- For Mattermost-ready standups, include a visible blank line before `Today:` and `Blockers:` section headers so copy/paste rendering is correct without manual edits.
 - When a flow/page shorthand could be ambiguous, prefer the real flow identifier and page name from `project-knowledge/03-context/workstreams/flow-page-references.md`.
 - For standups that may also be sent to Teams, prefer plain audience-friendly wording over internal implementation shorthand; avoid terms like `fallback` unless the audience already has the necessary context.
 - When a release is waiting on approvals or pipeline movement, make the concurrent work explicit so the update does not imply idle waiting.

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]
+focus: [pdiap-12284, pdiap-15836, rest-validation]
-work-items: [PDIAP-12284, PDIAP-15836]
+work-items: [PDIAP-12284, PDIAP-15836, PDIAP-15838]
-blockers: [xflowviewmaker-xflowsdk-dependency-mismatch]
+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`.
+- 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.
-- Separate code-correctness validation from environment/dependency blockers when reporting status.
+- 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.
-- After dependency alignment, rerun the targeted symbol/error/compile pass to confirm no stale enum names, host defaults, or dismissal sequencing regressions remain.
+- 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.
+- No current source-level compile blocker after manual dependency/build handling. Runtime host-path validation is still pending.
-- XFlowSDK SwiftPM validation is blocked in the current environment by missing `fidelity-src` registry configuration.

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.

prompts/standup.md

@@ -1,6 +1,6 @@
 # Standup Prompt
 
-> **Format note (2026-05-12):** Mattermost requires an extra blank line before section headers like `Today:` and `Blockers:` for proper rendering. The format template below reflects this.
+> **Format note (2026-05-13):** Mattermost requires a visible blank line before section headers like `Today:` and `Blockers:` for proper rendering. Always emit two newline characters between the previous bullet/list item and the next section header; never place `Today:` immediately after a list item.
 
 Use `project-knowledge/01-current/current-work.md`, `project-knowledge/01-current/work-items.md`, the detailed files referenced from that active-work summary, `project-knowledge/03-context/project.md`, `project-knowledge/03-context/workstreams/index.md`, `project-knowledge/03-context/process/communication.md`, `project-knowledge/04-people/manager.md`, the previous workday communication context, today's daily note if present, and the latest available communication context.
 
@@ -24,7 +24,7 @@ Generate a standup update for the active project profile.
 ## Output contract
 
 - Use the greeting required by the active profile or command. If no greeting is specified, omit the greeting and start with the previous-work section.
-- Return the greeting, a previous-work section, and `Today:`
+- Return the greeting, a previous-work section, and `Today:` with a visible blank line before `Today:`
 - Include `Blockers:` only when there is a real blocker to report; omit the entire section when there are no blockers
 - Use `Yesterday:` only when the previous-work section truly refers to yesterday; otherwise use a truthful label such as `Last workday:` or the weekday/date when clearer
 - Return Markdown that is ready to copy/paste directly into the configured team communication tool
@@ -105,4 +105,4 @@ Blockers:
 
 If there are no blockers, omit `Blockers:` entirely.
 
-**Mattermost rendering note:** use a blank line (an extra line break) before `Today:` and before `Blockers:` so Mattermost renders the section headers as proper headings rather than inline text.
+**Mattermost rendering note:** use a visible blank line (two newline characters) before `Today:` and before `Blockers:` so Mattermost renders the section headers as proper headings rather than inline text. Before returning the final answer, visually verify there is an empty line immediately above `Today:`.