david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: update work items and daily logs with May 12 entries, including REST backend deployment and validation meeting details

Browse Source
This commit is contained in:
David Delagneau
2026-05-12 07:24:04 -06:00
parent b5c3ada57d
commit 767f97f3bb
6 changed files with 33 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
project-knowledge/06-daily/2026-05-11.md
View File

@@ -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.