55 lines
3.0 KiB
Markdown
55 lines
3.0 KiB
Markdown
---
|
|
type: daily
|
|
project: fidelity
|
|
date: 2026-05-11
|
|
status: active
|
|
focus: [pdiap-12284, pdiap-15836, pdiap-15838]
|
|
work-items: [PDIAP-12284, PDIAP-15836, PDIAP-15838]
|
|
blockers: [fid4-validation-environment-warnings]
|
|
tags:
|
|
- daily
|
|
- fidelity
|
|
updated: 2026-05-11
|
|
---
|
|
|
|
# 2026-05-11
|
|
|
|
## Focus
|
|
|
|
- Continue the combined `PDIAP-12284` / `PDIAP-15836` work, with emphasis on the `PDIAP-12284` SwiftUI-host / UIKit-wrapper-removal path and dismissal-sequencing validation.
|
|
- Prepare Fid4 `4.32` for a likely REST-layer validation meeting, including release-branch setup, published `Podfile.lock` alignment, and XFlow entry-point readiness.
|
|
|
|
---
|
|
|
|
## Work Done
|
|
|
|
- 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.
|
|
|
|
---
|
|
|
|
## Findings
|
|
|
|
- The latest log review reported two dismissal sequences with the expected order: `endActivity` requested, dismiss requested, host received dismiss request, host disappearance confirmed, `fireEndActivityDelegates`, delegate event/exit callbacks, then `activitySession` cleared.
|
|
- 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 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`.
|
|
|
|
---
|
|
|
|
## 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.
|
|
- 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.
|
|
|
|
---
|
|
|
|
## 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.
|