chore: update work items and daily logs with May 12 entries, including REST backend deployment and validation meeting details
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
type: current
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-05-11
|
||||
updated: 2026-05-12
|
||||
tags:
|
||||
- current-work
|
||||
- fidelity
|
||||
@@ -47,6 +47,10 @@ tags:
|
||||
- The Fidelity-side AI tool Jeff referenced for this investigation is GitHub Copilot
|
||||
- Jeff later relayed that Adam says the latest build is now activating REST correctly, so David should switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles
|
||||
- For the upcoming REST-layer validation meeting, David prepared Fid4 `4.32` in a separate folder on the release branch, aligned it with the published/internal build `Podfile.lock` from iOSInstaller, and verified the project builds. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated entry point for quick XFlow validation.
|
||||
- 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.
|
||||
- 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
|
||||
- Current `PDIAP-15838` follow-up centers on the `PicoSDK` update in `SampleApp`: the newer Pico path removes the remaining transitive Apollo dependency, re-enables FGO and FidFolios testing in `SampleApp`, and aligns the sample implementation with current Fid4 usage
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
type: current-work-items
|
||||
project: fidelity
|
||||
status: active
|
||||
updated: 2026-05-11
|
||||
updated: 2026-05-12
|
||||
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.
|
||||
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.
|
||||
|
||||
- `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 11 validation is promising for dismissal sequencing, but merge/release still waits until after REST-transition consumer validation.
|
||||
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 11 validation is promising for dismissal sequencing, but merge/release still waits until after REST-transition consumer validation. Jeff confirmed the feature flag strategy should be implemented in this branch.
|
||||
|
||||
## Backlog / Future Reference
|
||||
|
||||
|
||||
@@ -15,3 +15,8 @@
|
||||
- Investigation: Differences from agents vs skills using agent, what is more general? correct relationship and use
|
||||
- Charles Proxy integration
|
||||
- LaunchDarkly integration
|
||||
- Teams integration
|
||||
- Photo uploader
|
||||
- Start as a service
|
||||
- Auto categorize by context
|
||||
- Multi photos session, copy multiples images in clipboard
|
||||
|
||||
@@ -8,7 +8,7 @@ systems: [xflowsdk, xflowviewmaker]
|
||||
workstreams: [xflow-swiftui-migration, consumer-integration]
|
||||
people: [jeff-dewitte]
|
||||
related: [pdiap-15836, pdiap-15838]
|
||||
updated: 2026-05-11
|
||||
updated: 2026-05-12
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
@@ -25,6 +25,7 @@ tags:
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
@@ -36,6 +37,7 @@ tags:
|
||||
- XFlowSDK should not be coupled directly to LaunchDarkly, Flagship, or app-specific feature-flag clients; it should receive an already-resolved host-mode decision.
|
||||
- If `hostMode` must be passed through `FlowConfig` or a similar object, keep it as adapter/internal plumbing rather than a new consumer-facing per-flow responsibility.
|
||||
- The latest tested run reported the expected dismissal order for the SwiftUI-host path, but the branch still needs review of the shared host-mode routing and any required broader validation before story closure.
|
||||
- Current code-review concerns to resolve before accepting the implementation: avoid unnecessary duplicate host-mode enums across XFlowViewMaker and XFlowSDK if one shared type can express the public contract safely; avoid naming that over-commits to `Fallback` if the toggle should be neutral and rollout-oriented; prefer a Fidelity-aligned boolean flag name using the `iOS-` prefix pattern when applicable; and review the new `AnyView` usage in `buildFlow` against safer SwiftUI alternatives.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -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-11
|
||||
updated: 2026-05-12
|
||||
tags:
|
||||
- work-item
|
||||
- fidelity
|
||||
@@ -89,6 +89,9 @@ tags:
|
||||
- Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days.
|
||||
- Branch maintenance is now part of the work: keep the GraphQL/Apollo-removal branch up to date with `main` until the REST backend/toggle validation window allows merge. If future `main` merges create conflicts that look non-trivial, raise it so a 1-2 point maintenance story can be created.
|
||||
- May 11 preparation for another REST-layer validation meeting: Fid4 `4.32` was checked out in a separate folder, aligned to the published/internal build `Podfile.lock` from iOSInstaller, and built successfully. Current XQ1 behavior appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST; `Open an account` is the simplest non-authenticated XFlow entry point to use for a quick readiness test.
|
||||
- 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.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -26,6 +26,8 @@ updated: 2026-05-11
|
||||
- Continued the `PDIAP-12284` implementation/validation loop with Copilot using a simulator console log from the current session.
|
||||
- Prepared a separate Fid4 project folder on the `4.32` release branch and used the `Podfile.lock` from the published/internal `4.32` build downloaded through iOSInstaller.
|
||||
- Built the Fid4 `4.32` setup successfully to verify readiness for the upcoming REST-layer validation session.
|
||||
- Jeff confirmed the feature flag strategy (host-mode resolution centralized in XFlowViewMaker) should be implemented as part of this branch's work.
|
||||
- Submitted weekly hours for the week ending May 9.
|
||||
|
||||
---
|
||||
|
||||
@@ -35,20 +37,29 @@ updated: 2026-05-11
|
||||
- The log review did not surface the key failure patterns that would invalidate the dismissal sequencing, such as delegate firing before host-disappearance confirmation or multiple host-disappearance confirmations for the same dismissal id.
|
||||
- Remaining non-XFlow log noise appears to be environment/integration related: Objective-C duplicate class warnings for `Secure` / `DeviceRisk` symbols from both `SecureDocV.framework` and `Fid4.debug.dylib`, Firebase configuration warnings, simulator noise, and raw device-token prints.
|
||||
- Treat the dismissal sequencing result as a promising validation run, but avoid calling the full story complete until the branch is reviewed and any required consumer validation is done.
|
||||
- Current code-review concerns for `PDIAP-12284`: avoid duplicating host-mode enums across XFlowViewMaker `FlowConfig` and XFlowSDK if a single shared/public type can safely express the contract; reconsider names that include `Fallback` if they make the feature sound temporary or removal-specific; align the feature-flag name with existing Fidelity style such as the `iOS-` prefix; and review whether the new `AnyView` usage in `buildFlow` is necessary or can be replaced with a type-safer SwiftUI alternative.
|
||||
- Current XQ1 validation appears to have `iOS-XflowRestEnabled` already active, so Fid4 is loading REST even before the planned toggle-change meeting.
|
||||
- The simplest non-authenticated Fid4 entry point identified for quick XFlow validation is `Open an account`.
|
||||
- **REST backend deployed** (per Jeff): the REST back end has 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 today ahead of the meeting — confirm XFlow comes up without issues while the flag is still in its current state.
|
||||
- **REST detection for the meeting**: use Charles Proxy to verify `/xflow/api` endpoints for REST path and inspect `mobile.launchdarkly.com` bulk payloads for the raw evaluated flag value.
|
||||
- **Production testing status**: Raj is trying to get approval to test in production. If approved, or if they simply flip the toggle 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.
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
- Continue reviewing the `PDIAP-12284` implementation and confirm the SwiftUI-host default path and temporary UIKit-hosted path are both routed and validated as intended.
|
||||
- Ask Copilot to evaluate host-mode type ownership, naming, flag naming, and `AnyView` alternatives before accepting the current diff.
|
||||
- Decide whether the duplicate `Secure` / `DeviceRisk` class warnings are only known environment noise or need separate follow-up before relying on the validation session.
|
||||
- Avoid sharing raw logs without redacting device-token prints.
|
||||
- Re-run a quick Fid4 `4.32` smoke test through `Open an account` and any other known entry points before the REST-layer validation meeting.
|
||||
- **Smoke-test Fid4 `4.32` non-REST flows today** before the May 12 meeting — open several XFlow entry points and confirm they load without issues in the current (likely REST, per XQ1 flag state) configuration.
|
||||
- Prepare for the May 12 REST-layer validation meeting: have Fid4 `4.32` running in simulator, Charles Proxy capturing, and the list of known Fid4 XFlow entry points ready for screen-share walkthrough with Jeff/the team lead.
|
||||
- Be ready to show both REST (`/xflow/api`) and non-REST (if the toggle is flipped) behavior during the meeting.
|
||||
|
||||
---
|
||||
|
||||
## Blockers
|
||||
|
||||
- No story blocker confirmed, but the Fid4 validation session includes duplicate-class warnings that may need triage if runtime casting/crash behavior appears during validation.
|
||||
- Production testing may require a test account that only Bruce currently has; coordination needed if the team decides to test in production during or after the May 12 meeting.
|
||||
|
||||
Reference in New Issue
Block a user