feat: update Mattermost rendering guidelines for standups and enhance daily logs with recent validation details
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
|
||||
@@ -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.
|
||||
- Quy already moved this story into the next sprint (`26Q2.6`); leave it in To Do until the sprint starts on Thursday.
|
||||
- Reopened after rollback and moved to In Progress on May 12.
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
49
project-knowledge/06-daily/2026-05-13.md
Normal file
49
project-knowledge/06-daily/2026-05-13.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user