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

Add daily logs and templates for project fidelity

Browse Source 
- Created daily log entries for May 13, 14, 18, 19, 20, and 21, capturing work done, findings, and next steps.
- Established a daily logs index for easy navigation of daily notes.
- Developed templates for daily logs, decisions, meeting notes, people, systems, and work items to standardize documentation.
- Introduced base files for filtering and displaying various types of project knowledge, including daily notes, decisions, people, systems, work items, and workstreams.
- Added maps for current work, fidelity apps, and fidelity domain to enhance project navigation and context.
This commit is contained in:
David Delagneau
2026-05-21 12:28:07 -06:00
parent 7cbb49134a
commit 1ad707373a
203 changed files with 449 additions and 434 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
workspaces/fidelity/project-knowledge/06-daily/2026-04-08.md Normal file
View File

@@ -0,0 +1,40 @@
---
type: daily
project: fidelity
date: 2026-04-08
focus: [ao-discourse]
work-items: [pdiap-15765]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-08
## Work Done
- Investigated a Youth account flow issue reported externally
- Compared the observed behavior against prior flow behavior
- Captured notes to explain the issue clearly before sharing updates
---
## Findings
- Reproduction required an authenticated user
- Behavior appeared consistent with previously observed flow behavior
- The report did not yet prove a regression
---
## Communication
- Prepared a clearer explanation for follow-up through Mattermost
- Framed the issue as an external report pending scope confirmation
---
## Next Step
- Confirm whether any additional action is needed before closing the issue

65
workspaces/fidelity/project-knowledge/06-daily/2026-04-09.md Normal file
View File

@@ -0,0 +1,65 @@
---
type: daily
project: fidelity
date: 2026-04-09
focus: [ao-discourse, xflow-swiftui-migration, rest-migration]
work-items: [pdiap-15765, pdiap-15836, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-09
## Work Done
- Refined manager-facing communication about a reported behavior difference
- Reframed ambiguous language before documenting the outcome in Jira
- Updated context to reflect auth-dependent behavior
- Confirmed the reported DOB validation issue only reproduces for authenticated users on TeenIdentityCheck
- Created `PDIAP-15836` for dismissal delegate lifecycle sequencing in pure SwiftUI (`8` points)
- Aligned `PDIAP-15838` scope with REST migration cleanup and feature-flag removal
- Confirmed XFlowViewMaker `0.5.0` is already in Fid4
- Updated the root cause document for the AccountLink dismissal sequencing issue tied to `PDIAP-15836` and got approval on the proposed wording
---
## Findings
- The reported behavior depended on authenticated context
- The original external report was incomplete
- The comparison needed more precise wording to avoid implying regression
- The dismissal sequencing change needs extra validation across flows, so the story was sized at 8 points
- The REST deprecation story covers Apollo, GraphQL networking code, related tests/mocks, and transport feature flags
---
## Communication
- Prepared clearer wording for Jeff
- Focused on context, observation, and action instead of vague comparison language
- Proposed a root cause document update and got confirmation on the revised wording
---
## Slack Archive Import
- Imported 2,500 historical Slack messages spanning `2023-01-26` to `2025-11-24`
- Channels covered: `fidelity-code-review`, `fidelity-grabaciones`, `fidelity-interface-meetings-on-calendar-outlook-team-etc`, `fidelity-jira`, `fidelity-preguntas`, `fidelity-reports-read-this-shit-no-excuses`, `fidelity-retrospective`, `fidelity-standup`
- High-signal historical themes: XFlow SwiftUI migration work, Jira/story approval threads, pipeline debugging, and manager-reviewed message wording
- Treated older pipeline and story details as historical evidence unless they still change current understanding
---
## Next Step
- Keep using explicit issue framing for future Mattermost and Jira updates
---
## Workflow Clarification
- This workspace is mainly used off the Fidelity work machine
- Main practical use cases are: drafting Mattermost updates to Jeff, translating/refining English, reusing prior context, getting Swift technical support, and drafting PR/story text
- Recommendations for new commands should prioritize communication support and context reuse over heavy local triage workflows that assume direct access to the product environment

48
workspaces/fidelity/project-knowledge/06-daily/2026-04-10.md Normal file
View File

@@ -0,0 +1,48 @@
---
type: daily
project: fidelity
date: 2026-04-10
focus: [xflow-swiftui-migration, rest-migration, ao-discourse]
work-items: [pdiap-14859, pdiap-15765, pdiap-15836, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-10
## Clarification
- `PDIAP-15838` should not be framed as directly tied to the UIKit-removal spike.
- Avoid wording that implies `PDIAP-15838` is dependent on or part of the dismissal-sequencing / UIKit-removal spike.
- Standups should prioritize updates directly tied to active work items and omit side questions such as version reminders that were only for internal context.
- Current focus for today is to finalize `PDIAP-14859` with a dual UIKit/SwiftUI plan that removes `UIHostingController` dynamically while preserving both flows appropriately.
- Omit standup items that are not directly related to a story.
- Use the approved title `Remove Apollo for iOS` for `PDIAP-15838`.
- When a documentation or root cause update directly supports a story, report it under that story instead of as a separate standup item.
- In standups, format Jira references as `ID - Title` or `ID Title`, not `ID, Title`.
- Jeff clarified that `PDIAP-15838` is the next story to work on and `PDIAP-15836` comes later.
- Clarification: the feature-flag and rollout planning feedback applies to the broader UIKit-removal spike, not only to the dismissal sequencing changes; the sequencing work should fit into that same consumer rollout plan.
- Current priority is to create a process-oriented document that explains the rollout plan Jeff described for the UIKit-removal spike, with the goal of sharing it for feedback.
- Clarification: the document should frame the work as a more deliberate migration phase toward the SwiftUI-only path, not as a correction to a prior failed attempt. The dismissal sequencing work is only one part of that broader migration plan.
- The document should clearly explain that the rollout uses a dual-path pattern to switch between the `UIHostingController` path and the SwiftUI-only path during migration.
- Jeff said the remaining spike deliverable is a clear consumer-facing rollout plan covering risky entry points like FTTransfer, consumer communication, XQ1 validation, a 30-day production period with no reported bugs, and a follow-up release to remove the feature flag and old code; he suggested sending that process-oriented document to Quy for feedback when ready.
- Reviewed the first Copilot-generated draft of the SwiftUI-only migration rollout document from screenshots.
- The draft already includes the main requested elements: dual-path rollout, `xflow-master-swiftui-enabled`, XQ1 validation, FTTransfer coordination, rollback handling, 30-day stabilization window, and final cleanup release.
- The next revision should shift the tone slightly away from formal incident/operations language and make the consumer rollout sequence, decision owners, and entry-point-based enablement flow feel more like an engineering migration plan than a generic release runbook.
- Correction for the next rollout-document revision: the rollout should not be framed as entry-point-based enablement; it uses a global feature flag and should emphasize broad XQ1 validation before any production release.
- Correction for audience framing: the document is consumer-facing and should avoid stakeholder-oriented wording.
- Further correction for the rollout document: it should not say production rollout begins with lower-risk consumers. The production flag is global and applies across flows together once the team decides to enable it.
- The document should present broad XQ1 validation as the required gate before any production rollout, not as one stage within a consumer-by-consumer enablement sequence.
- The migration framing should also call out that the rollout incorporates architectural improvements learned from prior SwiftUI iterations, especially where earlier approaches introduced SwiftUI anti-patterns.
- Reviewed the next screenshot-based revision of the rollout document. It now correctly reflects a global production flag model, broad XQ1 validation before production enablement, consumer-facing wording, and architectural improvements learned from prior SwiftUI iterations.
- Remaining polish areas in the latest draft: reduce lingering operational/runbook wording (`SLA`, `operational response`, `release manager delegate`, heavy monitoring-threshold language) and make the high-risk-consumer section sound more like coordination/validation within a global rollout than a separate rollout phase.
- The rollout document should be more concise and should not use an overly complex multi-phase model.
- Reviewed the newer simplified screenshot-based revision. The rollout structure is now much closer to the intended model: a simple gated flow of broad XQ1 validation, global production enablement, then a 30-day stabilization window before cleanup.
- Remaining issues in the latest draft are mostly wording and trimming: it still includes extra runbook-style sections such as `Production Monitoring and Guardrails`, `Coordination Model for High-Risk Consumers`, `Rollback and Operational Response`, and `Decision Gates Summary`, which may be more detail than needed for the concise consumer-facing version.
- Reviewed another screenshot-based revision after the simplification prompt. The top-level rollout flow is still good and concise, but the lower half of the document still retains most of the extra runbook-style sections, so the latest revision did not yet materially reduce those details.
- Clarified the AO/Discourse config explanation for the authenticated `TeenIdentityCheck` DOB issue: the requirement is not to rename the root from `birthDate` to `validations`; instead, the `validation-rules` payload should contain a JSON object whose root key is `validations`, and if the age gate is required it should include `eighteenOrAbove: true`, matching the `CheckIdentity` structure rather than relying on a separate transactional rule boolean like `"eighteen-or-above": true`.
- Further clarification for the same AO/Discourse thread: the reply should explicitly state that the earlier comment was referring to the literal `"eighteen-or-above": true` attribute inside the transactional-rules array, while still distinguishing that from the separate `validation-rules` structure.
- Additional clarification for the authenticated `TeenIdentityCheck` config issue: the `validation-rules` attribute is the structure that drives the check. `CheckIdentity` was already configured correctly. The `TeenIdentityCheck` problem had two parts: the wrong root key (`birthDate` instead of the expected `validations`) and the missing `eighteenOrAbove` attribute inside `validation-rules`.
- For the Rashmi reply, the intended closing clarification is that the previous `CheckIdentity` `validation-rules` shape is the expected model for `TeenIdentityCheck`, and a JSON snippet can be shared to show the expected structure directly.

27
workspaces/fidelity/project-knowledge/06-daily/2026-04-13.md Normal file
View File

@@ -0,0 +1,27 @@
---
type: daily
project: fidelity
date: 2026-04-13
focus: [xflow-swiftui-migration, ao-discourse, rest-migration]
work-items: [pdiap-14859, pdiap-15765, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-13
## Standup Context
- Corrected the approved title for `PDIAP-14859` to `Spike - Research strategy to remove final UIKit wrapping from XFlowSDK and XFlowViewMaker without disrupting consumer implementation`.
- Manual clarification for Monday standup: reference Friday work rather than the prior calendar day.
- Friday update for `PDIAP-14859`: created a draft rollout document for removing UIKit in favor of a SwiftUI-only path, including feature-flag planning.
- Today update: publish the rollout document for `PDIAP-14859` and continue with `PDIAP-15838` `Remove Apollo for iOS`.
- Standups should include story titles, not only Jira IDs, when the title is available.
## Mattermost Sync
- `PDIAP-14859`: sent Jeff the rollout draft for review after updating it around the global feature flag, broad `XQ1` validation, and the consumer-facing rollout flow.
- Jeff replied that he will review the `PDIAP-14859` document this morning.
- For `PDIAP-15765`, Jeff approved sending the config clarification that `CheckIdentity` was already correct and that `TeenIdentityCheck` needed the `validations` root key plus `eighteenOrAbove` inside `validation-rules`; the message was sent with an expected validation snippet.

81
workspaces/fidelity/project-knowledge/06-daily/2026-04-14.md Normal file
View File

@@ -0,0 +1,81 @@
---
type: daily
project: fidelity
date: 2026-04-14
focus: [xflow-swiftui-migration, ao-discourse, xflow-debugging]
work-items: [pdiap-14859, pdiap-15765, pdiap-15838]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-14
## Previous Workday Refresh
- `PDIAP-14859` rollout draft remained in revision on April 13 rather than being finalized; the work was limited to the specific draft changes requested in review, not a broad rewrite.
- The rollout document should rename the proposed flag from `xflow-master-swiftui-enabled` to `xflow-swiftui-enabled`.
- The first rollout phase should explicitly mention contacting consumers ahead of time and asking them to validate their flows in `XQ1`.
- The rollout document should remove overly technical wording and avoid implying there are no consumer-side changes without qualification.
- Current spike clarification: `FTTransfer` changes are no longer considered strictly required after applying the SwiftUI dismissal behavior correctly, but risky entry points still need explicit rollout coverage.
## AO / Discourse Findings
- The AO reply about `TeenIdentityCheck` was approved and sent after clarifying that `CheckIdentity` was already correct and that the `TeenIdentityCheck` issue was the missing `validations` root and missing `eighteenOrAbove` inside `validation-rules`.
- Later validation showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
- A `HybridBrokerage` scenario reproduces on both iOS and Android.
- A Youth flow (`Open an account` -> `Save & Invest for a child` -> `Fidelity Youth Account`) fails on iOS while working on Android.
- Current evidence suggests Android is more flexible when decoding rule variations, while iOS is stricter about the expected `validation-rules` structure in the Youth-flow scenario.
- The iOS-only Youth-flow discrepancy is the scenario currently aligned with the story-level client fix.
- The cross-platform `HybridBrokerage` scenario should stay scoped separately until it is clear whether it is a service/config issue or a distinct bug.
## Current Direction
- `PDIAP-14859` remains focused on incorporating rollout-document feedback and publishing a consumer-facing plan.
- `PDIAP-15838` remains the next implementation story after the rollout-document work is in a good state.
## New Investigation Note
- For the Murali group discussion, there appears to be usage of `ApexBridgingAddressComponent` through references in `XFlowPageApexItem`.
- If that usage is active, the dependency comes from `ApexKitV3`, which was expected to retain support after the earlier ApexKit removal.
- Current guidance from that discussion is to migrate toward `FDS` or `ApexKitSwiftUI`, but the exact replacement for `ApexBridgingAddressComponent` is still unclear and needs investigation and validation.
- Narrower wording for the current status: there are visible references at a glance, but it is not yet confirmed whether they are active or dead code; the next step is to validate with a run.
## Fresh Mattermost Sync
- Confirmed with breakpoints that `ApexBridgedAddressComponent` is not used when loading an address component; the observed path goes through `ApexGoogleAddressViewModel`.
- A follow-up review raised that the old component may still be used to load rules and appears in `XFloaValueChanger`, so it should not be treated as dead code without deeper verification.
- Current direction for that investigation is to be exhaustive and avoid assumptions before describing the old bridged path as unused.
- Clarification from the same thread: the remaining `ApexKitV3` reference does not cause build issues because `ApexKitSwiftUI` still depends on `ApexKitV3`.
- `PDIAP-14859` rollout-document follow-up: Jeff asked whether the FTTransfer section needed updating, and David confirmed the document had already been revised to clarify that root cause.
- Latest clarification in the Murali thread: `ApexBridgedAddressComponent` belonged to the old UIKit rule-handling flow. In the current implementation, rules are described as being handled through the SwiftUI path, parsed from the payload and applied through the `XFlowViewApadater` / `ViewModelAdapter` layer using `ApexGoogleAddressViewModel`.
- Clarification for the retro/ownership discussion: the earlier FTTransfer-side explanation was not fully wrong, but it was incomplete. The SwiftUI state behavior was a real symptom/effect on the consumer side; the deeper root cause was the dismissal flow handling that had not been covered correctly. The main gap was concluding consumer ownership before isolating that underlying dismissal root cause.
- Suggested clarification for Jeff and Aylwing: the dismissal issue should be framed as a corner case that was not simple to identify without deeper analysis. The FTTransfer-side SwiftUI behavior was still a real observed symptom, but the deeper root cause only became clear after more thorough investigation.
- Additional clarification for that same reply: the FTTransfer-side state-management behavior should be described as a real SwiftUI anti-pattern that can cause view/state identity loss. That behavior was valid to call out, but it still did not fully explain the deepest root cause until the dismissal-path analysis was completed.
- Jeff clarified the broader lesson: if ownership is still uncertain, the safer path is to roll back and continue investigating rather than make confident claims about consumer-side fault before the code is fully understood. The risk is loss of trust and reduced ability for the framework team to make authoritative calls independently.
- Jeff also clarified that in this case, if the root cause is architectural on the framework side, the team is not in an authoritative position to call out consumer code. His preferred pattern under uncertainty is rollback plus investigation rather than confident ownership claims.
## ApexKitV3 / Swift 6 Follow-up
- Jeff clarified that when the external team says they will stop support, they mean the dependency will be deleted, which would cause build errors on the XFlow side unless it is removed or replaced.
- Breakpoint and import-removal follow-up showed that removing `import ApexKitV3` across XFlow causes `23` compilation issues.
- Replacing those imports with `ApexKitSwiftUI` still leaves `13` build errors.
- Current high-confidence understanding is that XFlow still has meaningful dependency impact from `ApexKitV3`, and this is not just a trivial dead-code cleanup.
- Swift 6 support is not yet implemented; related work is planned under a `26Q3` backlog epic.
- New direction from Jeff after speaking with Quy: spend the rest of today researching the impact of this change and prepare a short Confluence write-up by EOD, preferably by `4:30 PM`.
- The requested write-up should cover what change is being requested, build-error and component impact, what needs retesting, which flows/components are affected, and the overall risk including whether consumers should be involved in testing.
- Jeff explicitly wants the document framed as carrying impact and consumer-testing risk if the change requires more than small adjustments.
- Confirmed wording note: Quy should be treated as Scrum Master in prompts and write-ups, not described generically as a stakeholder.
- Additional analysis context for the ApexKitV3 investigation: the Swift version change was reverted back to Swift 5, and the Pods were updated to the latest versions including `ApexKitSwiftUI 1.27.14`. The current question is whether the ApexKitV3-removal impact remains the same under that updated dependency baseline.
- Document-review guidance for the ApexKitV3 impact write-up: it should not read as if code changes have already been made, should stay understandable for a non-technical reader, and should avoid overcommitting on production impact where SwiftUI-vs-legacy-path usage is still being verified.
- Additional document-review guidance: if the write-up already recommends consumer testing, it should not hedge with wording like `if the change extends beyond small cleanup`. The risk section should stay internally consistent and reflect the current conclusion directly.
## Late-Day Outcome
- The ApexKitV3 impact write-up was revised with the requested wording changes, including using `Impacted Flows` and making consumer validation a direct recommendation rather than a conditional one.
- Jeff approved the ApexKitV3 write-up after those edits, and David published it and sent the Confluence link to Quy with a concise summary of the effort and risk.
- End-of-day direction for `PDIAP-14859`: the rollout document was approved as good enough, but it was not published on April 14. The next step is to publish it on the next workday, then comment the spike with `Spike Results:` links and the follow-up story link.
- The UIKit-removal follow-up story should be linked as a blocker for the reopened UIKit-removal work after the spike is closed out.
- End-of-day direction for `PDIAP-15765`: move the story back to In Progress on the next workday and focus on the authenticated iOS-only Youth `TeenIdentityCheck` gap so iOS handles the service response the same way as Android.
- The separate `HybridBrokerage` scenario remains distinct from the iOS-only Youth-flow issue and may need its own follow-up ticket if the service-side problem still stands after the client-side story is resumed.

61
workspaces/fidelity/project-knowledge/06-daily/2026-04-15.md Normal file
View File

@@ -0,0 +1,61 @@
---
type: daily
project: fidelity
date: 2026-04-15
focus: [xflow-swiftui-migration, ao-discourse]
work-items: [pdiap-14859, pdiap-15765]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-15
## Toggle Name Follow-up
- Additional historical context from Teams suggests the existing LaunchDarkly flag name `xflow-master-swiftui-enabled` was already shared in the Fid4 LaunchDarkly project as the SwiftUI toggle.
- User-provided historical references: Neetu Gupta asked for the SwiftUI toggle name and Jason Mandozzi replied with `xflow-master-swiftui-enabled` plus the LaunchDarkly link; in January 2025, Thomas Payne also asked whether the team was ready to activate that same toggle.
- Current interpretation: the team may be able to keep using the same flag name even though the rollout intent is now narrower. In the current rollout, toggling would switch only the final `UIHostingController` wrapping on or off, while SwiftUI remains in use either way.
- This historical evidence supports keeping the existing flag name if renaming would add friction, but the semantic mismatch should still be acknowledged when describing the rollout.
- Fresh clarification from Jeff on April 15: do not reuse the old SwiftUI LaunchDarkly flag for this rollout.
- New required flag name for the rollout document: `xflow-swiftui-container-enabled`.
- The rollout document should explicitly note that this new flag is `to be added in the future as part of implementation`.
- Jeff plans to ask later how to get the new flag added when implementation time comes.
## PDIAP-15765 Follow-up Drafting Context
- David plans to confirm that `PDIAP-15765` was moved from investigation back to In Progress.
- Current working interpretation: the `HybridBrokerageAccountOpening` / `JointIdentityCheck` behavior appears to be a different issue from the iOS-only Youth `TeenIdentityCheck` gap.
- This separate `HybridBrokerage` path currently appears consistent across iOS and Android, so it may be expected flow/service behavior rather than the same client-side defect.
- Confidence is still limited: David wants to re-check whether anything changed in that path before stating that conclusion too strongly.
- One reason for suspicion is that the validation appears to use `min: 10` and `max: 10`, which may indicate questionable or non-meaningful validation setup rather than the same decoding problem tracked in the iOS story.
- Latest clarification from David: the original iOS-only issue is specifically that iOS does not recognize rules when they come under the `birthDate` key.
- Once the payload was changed from `birthDate` to `validations`, the originally reported iOS issue no longer reproduced and the validation loaded correctly.
- Fresh guidance from Jeff after the Android reproduction: this follow-up question should be sent to Rashmi as a separate consumer-side confirmation request, not answered internally.
- Jeff asked that the message start with: `One follow-up question about the other issue I found while attempting to reproduce (this was what I had originally thought your team was reporting):`
- Jeff also wants the message to end by asking whether Rashmi thinks that behavior is a bug as well.
- Later clarification from Jeff: send Rashmi a separate message asking whether their team changed the service payload on their side, since the original iOS-only Youth issue no longer reproduces after the payload moved from `birthDate` to `validations`.
- Jeff's current framing: even if their side changed the payload and the issue no longer reproduces, the iOS-side handling gap likely still should be fixed because the problem was iOS-only.
## Jeff Context On AO Fallback Handling
- Jeff confirmed the minimal iOS fallback change is the right fix for this issue.
- He clarified that the preexisting fallback-style validation handling in XFlow exists largely to accommodate AO flows.
- Jeff's project history note: AO is the oldest service integration and has older, harder-to-change payload conventions, while newer consumer services were largely built through Slate and were the primary validation target during the SwiftUI refactor.
- That history explains why `validations` aligned better with newer SwiftUI work, while older AO payload shapes can still require explicit iOS fallback handling.
- Jeff's practical guidance: when the issue is AO-consumer-specific, iOS-only, and caused by a mismatch between what the AO service sends and what the SDK expects, the easiest fix is often to add the minimal compatibility fallback on iOS.
## PR Drafting Context
- The `xflow-for-ios` PR template currently uses sections `## What`, `## Why`, `## How`, `### Changes details`, and `## Missed anything?` with a final checklist.
- The April 15 iOS fix PR is a one-line change in `XFlowViewAdapterRepresentable.swift` for `.apxDateSelect`, adding `birthDate` as a fallback after `validations`.
- This PR should be described as a small compatibility bug fix for older AO-style payloads rather than as a broader Android-parity refactor.
- David opened the PR for this minimal iOS compatibility fix.
## Standup And Flow Naming Notes
- David prefers standups to use one top-level Jira bullet with indented sub-bullets when a single ticket has multiple updates.
- In recent standup wording, `Youth flow` should be treated as shorthand for the real flow ID `HybridYouthAccountOpening`.
- The relevant page in that flow is `TeenIdentityCheck`.
- The separate authenticated flow under discussion remains `HybridBrokerageAccountOpening`, with the relevant page `JointIdentityCheck`.

46
workspaces/fidelity/project-knowledge/06-daily/2026-04-16.md Normal file
View File

@@ -0,0 +1,46 @@
---
type: daily
project: fidelity
date: 2026-04-16
focus: [ao-discourse, xflow-debugging]
work-items: [pdiap-15765]
blockers: []
updated: 2026-04-16
tags:
- daily
- fidelity
---
# 2026-04-16
## Mattermost
- Jeff clarified that `PDIAP-15765` should not move to Done until the PR is merged.
- Santosh approved the PR, but one code-owner approval is still required before merge.
- Jeff asked for one more AO working-group Teams reply that:
- summarizes that the original iOS issue was reproduced and addressed with the iOS-side change
- points the group to the Jira comment, Discourse comment, and PR
- explains that the initially found `HybridBrokerageAccountOpening` / `JointIdentityCheck` problem is separate
- notes which service-side changes were already made and which still appear to be needed
- David clarified that the confirmed service-side change was limited to the Youth-flow `TeenIdentityCheck` path. For external communication, avoid overstating the scope or calling out Rashmi by name unless that attribution is specifically needed.
- David clarified that the iOS change should be described as a compatibility improvement to reduce similar future issues with the older `birthDate` format. It should not be described in a way that implies it also applies to the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue.
- Jeff said the AO working-group draft was still confusing and wanted to edit it himself to make it very clear and avoid follow-up questions.
- David clarified that the `HybridYouthAccountOpening` / `TeenIdentityCheck` issue was iOS-only; it should not be described as affecting both iOS and Android.
- David clarified that the service-side change and the iOS-side fallback address the same Youth / `TeenIdentityCheck` issue, not two separate Youth issues. The service change was the immediate resolution, while the iOS PR is a compatibility safeguard if that older `birthDate` format appears again.
- David has personally seen `birthDate` used on two pages so far, but broader reuse in other flows is still unconfirmed and should be described carefully.
- For Jeff's framing question, the current understanding is two affected flow scenarios, not three: the iOS-only Youth / `TeenIdentityCheck` issue, and the separate cross-platform `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue.
- Jeff confirmed on April 15 that the minimal iOS `birthDate` fallback is the right change for the Youth / `TeenIdentityCheck` case and approved opening the PR under the same story.
- Jeff clarified the historical reason for the fallback behavior: older AO services often still use older payload conventions, while the SwiftUI refactor was validated more heavily against newer Slate-based services using `validations`.
- Jeff said the easiest fix is usually this kind of iOS-side fallback when the consumer is AO, the issue is iOS-only, and the service payload shape differs from what the SDK expects.
- Jeff approved the Jira and Discourse comments with one wording change: say `I checked the original iOS issue again` instead of `I re-checked`.
- Jeff approved sending a final AO working-group summary, but wanted it to be much clearer about what was fixed on iOS, what Rashmi changed on the service side, and what separate service-side issue still remains in `HybridBrokerageAccountOpening` / `JointIdentityCheck`.
- David later checked Cogstore and confirmed that the relevant flow-definition change tied to Rashmi's service update is already in QA as version `0.0.142`, while Production is still on `0.0.133`, so that flow change is not live in production yet.
- Jeff concluded there is no point relying on a separate service release for the Youth issue if it would also require its own rollout; the iOS PR should be treated as the primary fix path, while the QA-side flow-definition change explains why the issue no longer reproduces in XQ1.
- Durable tooling/system note: in Fidelity flow work, Cogstore is the platform used to modify and publish many individual flow configurations, compare versions per flow, and check who/when a specific flow version was published to QA or Production. Slate was the newer consumer-side configuration tooling during the SwiftUI refactor, but Jeff believes it is now decommissioned.
- Additional tooling note: flow IDs are not guaranteed to exist in both Cogstore and Slate, so the active configuration source for a given flow should be verified instead of assumed.
- David confirmed that the `HybridBrokerageAccountOpening` / `JointIdentityCheck` flow-definition content is the same in QA and Production even though the versions differ (`0.0.267` vs `0.0.263`), so that separate rule-content issue should also be reproducible in Production.
- Jeff asked Rashmi to revert the Youth-flow service change so the iOS-side PR can remain the single fix path for that issue.
- David confirmed Rashmi reverted the QA change by publishing the earlier flow version, and local Fid4 validation with the iOS PR showed the `birthDate`-based validation now works as expected.
- Jeff's preferred external summary is now very explicit: we went back and fixed their original iOS-only issue on the iOS side, while the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue is a new service-side problem that still needs its own follow-up.
- The `PDIAP-15765` PR later received final approval, was merged, and the release pipeline produced XFlow `2.8.48`.
- After the XFlow release, David updated XFlowViewMaker to `2.8.48`, opened the follow-up PR, and sent it for review so the fix can propagate through the consumer path.
- David also sent the final AO working-group update with links to the Jira story, Discourse ticket, and PR.

99
workspaces/fidelity/project-knowledge/06-daily/2026-04-17.md Normal file
View File

@@ -0,0 +1,99 @@
---
type: daily
project: fidelity
date: 2026-04-17
focus: [ao-discourse, consumer-integration, rest-migration]
work-items: [pdiap-15765, pdiap-15838]
blockers: []
updated: 2026-04-17
tags:
- daily
- fidelity
---
# 2026-04-17
## Standup Draft Clarification
- David clarified that the XFlowViewMaker follow-up work for `PDIAP-15765` is further along than the earlier summary implied.
- The XFlowViewMaker PR is already open and has some approvals.
- One FTFrameworks code-owner approval is still required before the PR can merge.
- After that approval, the remaining work is to run the pipeline and update Fid4 so the XFlow `2.8.48` change propagates through the consumer path.
- `PDIAP-15838` remains the next story after the `PDIAP-15765` propagation steps are in a good place.
- David's current plan is to ping Tauf for that remaining approval.
## Standup Wording Feedback
- Jeff said not to use `fallback` in the standup wording because a broader audience will not understand that term without extra context; prefer plain outcome wording like `Got the PR approved`.
- Jeff clarified that when `PDIAP-15765` is waiting on approvals or pipeline movement, the standup should explicitly say David is returning to GraphQL removal work rather than sounding like the day is blocked on waiting.
- David updated the standup wording with those changes and sent the final version.
## Learning Session - Release Propagation
- David clarified the current release propagation chain for XFlow changes.
- XFlowSDK is released from `pr100660-xflow-for-ios` through Jenkins pipeline `xflow-for-ios-publish`, which builds the XCFramework, publishes it to `artifactory.fmr.com`, and publishes the podspec to `ap010981-ios_podspecs_3x`.
- XFlowViewMaker lives in `PR100660-ios-frameworks/Adapters/XFlowViewMaker`; after an XFlowSDK release, its podspec must be updated, then `tuist generate -n`, `pod install`, PR review, protected-branch/code-owner approval, merge, and `publish-XFlowViewMaker` publication are required.
- The XFlowViewMaker publish pipeline usually auto-detects the next release and commonly auto-increments the minor version.
- Fid4 then consumes the new XFlowViewMaker version from `ap010981-ios-flagship-app` by updating the Podfile, running `tuist generate -n` and `pod install --repo-update`, opening a PR, and merging it before the downstream app release process carries the change to users.
- This release chain is durable context for understanding why an XFlowSDK fix can be merged and released but still not be visible yet in Fid4.
- David clarified that Fid4 consumes XFlow only through XFlowViewMaker, not directly through XFlowSDK.
- David also clarified that other frameworks such as `FTAccountOpen` and `FTTransfer` use XFlowViewMaker, and the practical Account Opening path is currently understood to go through `FTAccountOpen`.
- Version verification in Fid4 is imperfect because `Podfile.lock` is ignored in the repo; fixed Podfile references and pipeline artifacts can help verify released versions, but podspec-repo edits can still change what gets resolved later.
- Tauf was identified as a CI/Jenkins support contact who has helped with pipeline issues in the past.
- David clarified that Tauf's full name is `Taufiqur Ashrafy`; he is often referred to informally as `Tauf`.
- David also noted that Fidelity Teams may display people in surname-first order, which can make person matching less obvious across tools.
- David clarified that the surname-first display in Fidelity Teams is consistent for everyone.
- David also clarified that Teams and Mattermost represent different social contexts; outside of Jeff, people seen in Teams are generally not the same people David interacts with through Mattermost.
- David corrected current people status: Norman Arauz and Derian Cordoba no longer work with the current All-Win Software / Mattermost / Slack group, and Erik Reynolds previously worked for Fidelity but no longer does.
- David clarified an important working-context rule: Jeff is the only person who regularly communicates with Fidelity-side Teams stakeholders, while David works from the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.
## Mattermost Refresh - Dependency Conflict
- After XFlowViewMaker was published, David hit a dependency conflict while trying to update Fid4.
- The conflict appears to come from `FTAccountOpen` and `FTTransfer` depending on XFlowViewMaker with constraints that do not yet allow the new version.
- David noted that Tauf has handled similar cases before by updating the constraint directly in the podspec repo.
- Jeff asked David to message Tauf, ask him to remind David what he does in this case, and then document the process for future reference.
- Follow-up Teams evidence from Tauf clarified the practical fix path:
- first try `pod install`
- if resolution still does not move to the latest XFlowViewMaker version, the change belongs in the podspec repo, not in FTFrameworks
- `FTAccountOpen` and `FTTransfer` do not appear to hold a direct XFlowViewMaker version reference in their FTFrameworks source podspec files; the effective versioning is handled through the published podspec layer and the `ftAdapter` function
- David later clarified the actual fix: in the podspec repo PR, he removed the XFlowViewMaker version reference from both the latest `FTAccountOpen` and `FTTransfer` podspecs
- Tauf approved that podspec-repo PR
- After that merge, `pod install --repo-update` worked in Fid4 because the published podspecs no longer constrained the XFlowViewMaker version
## Mattermost Refresh - Release Progress
- The remaining XFlowViewMaker code-owner approval was obtained from Tauf, allowing the release process to continue.
- The XFlowViewMaker release was published successfully.
- David then opened the Fid4 PR with the latest versions and planned to request reviews from Santosh and Tauf.
- Later the Flagship/Fid4 PR was approved and merged.
- David planned to move `PDIAP-15765` to Done after that downstream merge.
## Mattermost Refresh - Urgent REST Validation
- Jeff redirected work to an urgent consumer report claiming REST calls were failing on iOS when the toggle was enabled.
- David clarified that David does not have access to Flagship LaunchDarkly projects; only the sample app LD project is available from David's side.
- David tested locally on `main` and reported that REST loaded correctly with the `iOS-XflowRestEnabled` flag enabled.
- David also verified that XFlow `2.8.47` already supports that flag and is present in the 4.30 line used for consumer validation.
- David later verified on the `release/4.30` branch that the behavior still looked correct there.
- Current working hypothesis: the consumer report may reflect a version mismatch or incorrect flag configuration rather than a reproducible iOS REST failure in current local validation.
- Adam's `trunk build` reference appears to mean a real-device build platform that can provide downloadable App Store/internal IPAs and a dependency snapshot such as `Podfile.lock`, even though David cannot run those IPAs on simulators.
## Communication Correction
- David corrected a drafting mistake: when proposing a message that David will send directly to a Fidelity-side contact, the wording must not imply Jeff is the sender or that the recipient already knows David through Jeff.
- For this kind of direct outreach, avoid phrases like `Jeff mentioned...` unless David explicitly wants that framing.
- David made a second correction: if Jeff asked for internal documentation or future-process capture, that should stay internal and should not be surfaced in David's external message unless explicitly requested.
## Mattermost Refresh - Dependency Reproduction Caution
- Jeff asked David to compare against the dependency snapshot from the device-oriented trunk build context to reduce uncertainty about the reported REST behavior.
- David noted that downloading the referenced `Podfile.lock` and running `pod install` is a useful approximation, but still not a full guarantee if the private podspec repo changed after that build was produced.
- If exact dependency reproduction is required, the stronger path is to also check out the podspec repo at the matching earlier revision instead of relying on `Podfile.lock` alone.
## Learning Correction - Build Inspection Sources
- David clarified that `iosinstaller` is one of Fidelity's internal apps for inspecting distributed consumer builds.
- `iosinstaller` can download App Store and internal builds and also expose the corresponding `Podfile.lock`.
- David also clarified a useful app-store debugging path in the Flagship app pipeline: the artifact `appstore/DistributionSummary.plist` records the framework versions installed for that build.
- That artifact can be used to confirm which XFlowViewMaker and XFlow versions were actually installed in a specific App Store build.

79
workspaces/fidelity/project-knowledge/06-daily/2026-04-20.md Normal file
View File

@@ -0,0 +1,79 @@
---
type: daily
project: fidelity
date: 2026-04-20
status: active
focus: [rest-migration]
work-items: [pdiap-15838]
blockers: []
tags:
- daily
- fidelity
updated: 2026-04-20
---
# 2026-04-20
## Focus
- Prioritize investigation into why REST is not activating on iOS.
- Continue `PDIAP-15838` with the investigation as the immediate focus.
---
## Work Done
- Continued the REST activation investigation tied to `PDIAP-15838`.
- Refined the current Apollo-removal analysis and next implementation order for `PDIAP-15838`.
---
## Findings
- The immediate priority is no longer closeout work on the completed stories.
- The immediate priority is to investigate why REST is not activating.
- The earlier `Done` transitions for `PDIAP-15765` and `PDIAP-14859` should not be treated as April 20 work; they happened before this workday and should not be repeated in standups for this date.
- David confirmed the production build already contains the commit that added the LaunchDarkly flag, so the working hypothesis should move away from "missing code in production build" and toward LaunchDarkly evaluation context, targeting, initialization timing, or downstream gating conditions.
- David has source-code access and can use Charles Proxy during local investigation, but does not yet know where the LaunchDarkly context attributes are assembled on iOS.
- Jeff explicitly confirmed the REST-flag investigation should remain the priority over Adam's separate service-side flow issue.
- Jeff wants faster progress on the REST-flag investigation and asked David to keep him updated while continuing the current research.
- Jeff suggested using outside help while the direct Flagship LaunchDarkly access gap remains: monitor the Tauf thread, follow the redirect to Jeffrey O'Leary, describe the issue in detail to the AI tool with build settings and tool details, and ask Aylwing for a quick sanity check if available.
- Jeff referred to GitHub Copilot as the Fidelity-side AI tool that may produce better results when David provides richer local product context than Jeff can summarize indirectly.
- Current local evidence says the LaunchDarkly boolean evaluates to `true`, the payload is present, and the context is being sent; the remaining questionable area is whether the production-side context or timing is still affecting real-device behavior.
- A plausible fallback explanation, if the issue reappears, is a real-device-only environment difference rather than business logic alone, including LaunchDarkly context interpretation, timing, or cached toggle state that would not match the simulator path.
- Adam Abdelhadi was the reported source of the REST activation problem, and his side validates behavior on real devices.
- Jeff later relayed that Adam says the latest build is now activating REST correctly, so the urgent production-toggle investigation is no longer the immediate focus.
- Jeff directed David to switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles.
- AI-assisted codebase analysis for `PDIAP-15838` says the main remaining Apollo blockers are residual `XFlow.Slot` model coupling in the page interactor/worker path, init/session lifecycle coupling to `NetworkClient`, and remaining Apollo build/dependency wiring.
- The proposed safe order is: replace `XFlow.Slot` with a transport-agnostic type first, decouple init/session from `NetworkClient` without changing REST endpoint behavior, then remove runtime GraphQL code, Apollo project wiring, Apollo-only tests/scripts/docs, and treat any PicoSDK-transitive Apollo dependency as a later dependency-exit step.
- The current risk is no longer GraphQL transport itself; it is hidden runtime or public-API coupling plus the chance of claiming full Apollo removal while a transitive dependency still exists through PicoSDK.
- Follow-up AI analysis says the `XFlow.Slot` replacement may be simpler than expected: no new model may be needed because `activitySession?.stagedValues()` already yields `[String: String]` and `XFlowUpdateSlotsRequest.slots` already accepts `[String: String]`. If that holds in code, the current Apollo dependency is mostly an unnecessary intermediate conversion step.
- Local trial changes showed that `XFlow.Slot` is likely not the only remaining Apollo-dependent model in the first-step cleanup path, so the next Copilot pass should validate the real dependency surface through `xcodebuild` errors instead of assuming static references tell the whole story.
- Additional Copilot validation on Apollo-generated enums says the checked production callers for `XFlow.ContentType`, `XFlow.ScreenshotFormat`, and `XFlow.NextTransitionType` appear to need only native `String`-backed enums plus the current local fallback behavior, not Apollo `EnumType` semantics.
- Current design preference for the Apollo cleanup is to keep domain-facing code using a native `Slot` model and limit `[String: String]` to the REST boundary/DTO construction layer instead of pushing the dictionary type through the full interactor/worker path.
- David clarified additional Fidelity-side process context: Quy acts as Scrum Master, manages retrospectives, DSE/daily syncs, sprint review, and sprint planning, retrospectives use Miro, Jira is the tracking system, and the Fidelity-side sprint cadence is two weeks with labels like `PDIAP 26Q1.1` and `PDIAP 26Q2.1`.
- David corrected the Q2 sprint examples: `PDIAP 26Q2.1` is `3/26 - 4/09`, and `PDIAP 26Q2.2` is `4/09 - 4/23`.
- David clarified that Jira should be represented as a first-class Fidelity tool/system because it is used more heavily than Confluence in day-to-day work tracking.
- David clarified that `PDIAP-15838` is assigned to the next sprint, so it should not be described as current-sprint in-progress implementation work.
---
## Communication
-
---
## Next Steps
- Investigate why REST is not activating on iOS.
- Inspect where iOS builds and identifies the LaunchDarkly context so local logs and Charles captures can confirm which attributes are actually sent.
- Package the current reproduction details for the AI tool, including build settings and the external tool being used.
- Keep watching the outreach thread with Tauf / Jeffrey O'Leary and ask Aylwing for a quick perspective if he is available.
- Resume `PDIAP-15838` implementation work for removing GraphQL and related LaunchDarkly toggles.
---
## Blockers
- None currently.

66
workspaces/fidelity/project-knowledge/06-daily/2026-04-21.md Normal file
View File

@@ -0,0 +1,66 @@
---
type: daily
project: fidelity
date: 2026-04-21
status: active
focus: [rest-migration, xflow-swiftui-migration]
work-items: [pdiap-15838, pdiap-15836]
blockers: []
tags:
- daily
- fidelity
updated: 2026-04-21
---
# 2026-04-21
## Focus
- Continue `PDIAP-15838` Apollo-removal cleanup.
- Continue validating the Apollo-removal state.
- If time allows, publish new XFlow and XFlowViewMaker versions.
---
## Work Done
- Cleaned up the active production model layer so it no longer depends on Apollo-generated models for the current path.
- Removed the three `NetworkClient.shared.updateAppSyncURL(...)` calls from `XFlowInitManager` and removed `getAppSyncEndPoint()` after it became unused; the project still compiles.
- Updated the Confluence/root-cause document for the FTTransfer discussion so it now reflects the current recommendation.
- Removed the `ApolloGeneratedCode` runtime tree and its project wiring from XFlowSDK.
---
## Findings
- The model-decoupling step for `PDIAP-15838` is now in a cleaner state.
- The next focus should shift to the remaining Apollo-dependent runtime and infrastructure surface: init/session coupling through `NetworkClient`, Apollo-generated/runtime code that is no longer needed, and Apollo-specific tests/scripts/build wiring.
- Any Apollo dependency that remains only through PicoSDK should be treated separately from source-level cleanup.
- Copilot's focused runtime/init guidance says the safest next source-level step is to remove only the three `updateAppSyncURL(...)` calls from `XFlowInitManager`, then delete internal `getAppSyncEndPoint()` if it becomes unused, while leaving `NetworkClient.swift` and `XFlowInitManagerConfig.swift` in place temporarily as disconnected compatibility surface until later cleanup.
- After that step, no live init/session runtime wiring from `XFlowInitManager` into Apollo/AppSync remains; the remaining Apollo surface appears to be disconnected compatibility/runtime code plus later package/build/test cleanup.
- Follow-up scan says `GraphQL/NetworkClient.swift` now appears runtime-dead for production, `GraphQL/ApolloGeneratedCode` appears unreferenced by production runtime after model cleanup, and the safest next step is to remove `NetworkClient.swift` first, then validate before removing `ApolloGeneratedCode`.
- Broader Apollo cleanup has now removed `NetworkClient.swift`, `ApolloGeneratedCode`, Apollo-specific test files/mocks, and related project-file entries. Current reported state says production code has zero live Apollo imports/references and retained REST behavior, while remaining follow-up work is package/build cleanup plus the deferred compatibility API surface in `XFlowInitManagerConfig.swift`.
- Test-target cleanup is now also in a good state: a minimal update to `XFlowTransportSelectionTests.swift` removed obsolete GraphQL/Apollo assertions, preserved REST-oriented coverage, and left no remaining non-environment test-target compile errors.
- The latest cleanup pass also removed the remaining direct Apollo package/build references, so the story is now in a cleaner post-removal state and ready for consumer-side validation from Fid4.
- The current FTTransfer communication should say the primary fix is the dismissal adjustment in the UIKit hosting path; FTTransfer-side improvements are secondary and not strictly required to reproduce the same visual behavior.
- After the `ApolloGeneratedCode` removal, local compilation still succeeds for David; the Copilot-reported `ApexKitSwiftUI` blocker should be treated as environment-specific noise unless it becomes reproducible in the real local build.
- No live production Apollo runtime references remain in `XFlowSDK/XFlowSDK`; the next cleanup surface is deferred test references plus any intentionally retained AppSync compatibility APIs.
---
## Next Steps
- Confirm whether `NetworkClient.swift` still has any live production callers or can now be treated as removable runtime dead code.
- Confirm whether `XFlowInitManagerConfig.swift` AppSync getters are truly compatibility-only or still externally used.
- Identify the runtime Apollo files that can now be removed safely after the model and init cleanup.
- Remove Apollo-only tests, mocks, codegen scripts, and build wiring once runtime references are gone.
- Treat any transitive PicoSDK Apollo dependency as a separate dependency-exit step.
- Continue cleanup by removing GraphQL/Apollo-era test references and related test-only helpers without changing production runtime behavior.
- Continue validating the Apollo-removal state today.
- If time allows, publish new XFlow and XFlowViewMaker versions.
---
## Blockers
- None currently.

45
workspaces/fidelity/project-knowledge/06-daily/2026-04-27.md Normal file
View File

@@ -0,0 +1,45 @@
---
type: daily
project: fidelity
date: 2026-04-27
status: active
focus: [rest-migration]
work-items: [pdiap-15838]
blockers: []
tags:
- daily
- fidelity
updated: 2026-04-27
---
# 2026-04-27
## Focus
- Continue Apollo-removal cleanup and validation follow-up for `PDIAP-15838`.
---
## Findings
- Jeff asked that if a PR is opened today, it should not be merged yet because the REST backend is still waiting to be deployed to production.
- Bruce reinforced the same sequencing: do not merge the GraphQL/Apollo removal work until the backend is in production because GraphQL fallback is still needed before then.
- Bruce said there are no REST changes to the SDK side for the current backend-readiness work; the functional fix is on the Flagship/Fid4 side, while the SDK-side updates are cleanup, more graceful error handling, logging, and replacing a deprecated logger interface.
- Bruce asked whether iOS Fid4 has a release-build optimization or code-minification concept comparable to Android, likely to understand whether build configuration could affect validation or runtime behavior in production-style builds.
- Jeff clarified that the immediate ask is not to find a literal `minification` setting, but to inspect whether Fid4 is built differently for simulator versus physical-device/generated builds, including any build-size, optimization, or release-style settings that could match what Bruce described.
- David identified the most likely Fid4 build differences to report back: Trunk/generated builds compile with the `Release` configuration while local runs are usually `Debug`; optimization settings such as `SWIFT_OPTIMIZATION_LEVEL` and `GCC_OPTIMIZATION_LEVEL` differ; Jenkins uses a generated `build-overrides` xcconfig that local builds do not use and may alter values such as secrets; and dependency resolution can vary depending on the local CocoaPods specs repo state.
- David reviewed what may still be pending and noticed that `SampleApp` depends on `PicoSDK`, which still brings Apollo transitively in the current setup.
- The likely recommendation is to move `PicoSDK` to a newer version because newer releases no longer depend on Apollo.
- That upgrade path does include breaking changes. The current follow-up is to figure out how to handle them in `SampleApp` by comparing against how `Fid4` currently uses `PicoSDK` for the two specific flows that still depend on it.
- The current `PicoSDK` update also requires re-enabling the `FGO` and `FidFolios` flows in `SampleApp` for validation there; without this update, the Pico endpoint path fails in the sample app.
- Jeff confirmed this `PicoSDK` / `SampleApp` work should be treated as in scope because Apollo must be removed from the project, including the transitive `SampleApp` path used through `PicoSDK`.
- Important scope nuance: updating `PicoSDK` affects `SampleApp`, not `XFlowSDK` production runtime itself.
---
## Next Steps
- Hold any PR merge until the REST backend is deployed to production.
- Check Fid4 build settings/schemes/configurations for simulator-versus-device differences, especially release/generated-build optimization or size-related settings that could explain behavior seen in generated builds but not local runs.
- Investigate the `PicoSDK` upgrade path in `SampleApp`, using the current `Fid4` integration for the two affected flows as the comparison point for handling the breaking changes safely.
- Include the `PicoSDK` / `SampleApp` update in the current Apollo-removal PR.

45
workspaces/fidelity/project-knowledge/06-daily/2026-04-28.md Normal file
View File

@@ -0,0 +1,45 @@
---
type: daily
project: fidelity
date: 2026-04-28
status: active
focus: [rest-migration, ao-discourse]
work-items: [pdiap-15838]
blockers: []
tags:
- daily
- fidelity
updated: 2026-04-28
---
# 2026-04-28
## Focus
- Continue `PDIAP-15838` Apollo-removal work, especially clearing the remaining transitive `PicoSDK` dependency from `SampleApp`.
- Start investigating the new Discourse-reported FTTransfer / AccountLink issue after the draft PR is open.
---
## Findings
- For `PDIAP-15838`, David updated `SampleApp` to use a newer `PicoSDK` path that no longer brings Apollo transitively, so Apollo is removed from the sample app dependency path as well as the direct XFlow cleanup path.
- The `PicoSDK` update re-enabled the FGO and FidFolios flows for testing in `SampleApp`; without the update, the Pico endpoint fails.
- Jeff confirmed the `SampleApp` / `PicoSDK` update is in scope for `PDIAP-15838` because Apollo needs to be removed from the project, and the sample app should stay aligned with how Fid4 consumes Pico.
- David clarified that the `PicoSDK` update affects `SampleApp`, not the `XFlowSDK` production runtime directly, and aligns `SampleApp` with the newer Pico usage already present in Fid4.
- A draft PR for `PDIAP-15838 - Remove Apollo for iOS` was opened for internal review before sending to Bruce.
- Aylwing reviewed the draft PR and raised questions around intentional removal of the REST kill switch, `PicoSDKManager` initialization ownership, resolver availability, and async completion returning to the main actor.
- Jeff confirmed removal of the REST kill switch is intentional for permanent GraphQL deprecation, but the PR should merge only after the previous REST-toggle implementation has been QA-tested and active in production with REST enabled for all consumers for 30 days without issues.
- David confirmed `TransactionContextManager(resolver:)` handles Pico setup internally in `PicoSDK 4.3.18` through lazy resolver-based initialization, and the `SampleAppAuthDependencyResolver` is already available from the view model.
- David confirmed the resolver is an existing `XFlowSampleAppViewModel` property.
- David applied a minimal `PicoInterface` patch so the `Task` does not strongly capture `self` and both completion paths return through `MainActor.run`, making UI-state callers safer.
- After internal review, the next handoff is to send the draft PR link to Bruce.
- A new Discourse report came in around an AccountLink / FTTransfer multiple-presentation or web-view rewrite issue. Earlier UIKit-removal investigation had ruled out that change as the cause, but Zachary provided additional detail and believes it may still come from XFlow, so ownership needs careful reproduction before suggesting it is outside XFlow.
---
## Next Steps
- Send the `PDIAP-15838` draft PR to Bruce after internal review is ready.
- Keep the `PDIAP-15838` PR in draft/review state until the REST production-readiness window is satisfied.
- Continue investigating the Discourse-reported FTTransfer / AccountLink issue and confirm reproduction/ownership before proposing a story or suggesting it is outside XFlow.

61
workspaces/fidelity/project-knowledge/06-daily/2026-04-29.md Normal file
View File

@@ -0,0 +1,61 @@
---
type: daily
project: fidelity
date: 2026-04-29
status: active
focus: [ao-discourse]
work-items: []
blockers: []
tags:
- daily
- fidelity
updated: 2026-04-30
---
# 2026-04-29
## Focus
- Continue investigating the Discourse-reported FTTransfer / AccountLink reproduction path.
---
## Work Done
- David successfully configured the `FTTransferPlayground` environment.
- For the version Zachary mentioned, David did not find a matching branch; the closest match found was the tag `Release/Foundation/5.0.0-beta.24`, assumed to correspond to the `5.0.24 beta` version Zachary referenced.
- David reached the flow so it now looks similar to Zachary's video, but the app asks for phone-number verification before the web view loads.
- David asked Zachary for reproduction details, including whether the issue reproduces in `Fid4` and which account/steps were used.
- With the account Zachary shared, David reproduced the issue in `FTTransferPlayground`.
- David tested the same account in `Fid4`, but the issue did not reproduce there.
- David narrowed the visible issue to the `BankInformationView` path rather than XFlow directly: an XFlow flow occurs before the web view is presented, but it finishes before `BankInformationView` takes over.
---
## Findings
- The issue occurs when tapping `exit`: the alert appears, but the view immediately rebuilds.
- The behavior currently looks like a SwiftUI recomposition issue: `.state` is updated to `.loading`, which triggers a redraw, presents an `EmptyView`, dismisses the alert, and reloads the web view.
- The remaining uncertainty is why this happens in `FTTransferPlayground` but not in `Fid4`.
---
## Communication
- David updated Jeff with the `FTTransferPlayground` setup status and the current verification blocker.
- Jeff asked David to ping Zachary directly for help, including asking whether Zachary has seen the issue in `Fid4` and how David might reproduce it there.
- David reported that the issue reproduces in `FTTransferPlayground` with Zachary's account but not in `Fid4` with the same account.
- Jeff asked David to prioritize resolving the Discourse consumer issue by end of day on April 30 if possible.
---
## Next Steps
- Continue deeper testing to isolate why the behavior occurs in `FTTransferPlayground` but not in `Fid4`.
- Verify the root cause and whether there is any remaining relationship to XFlowViewMaker before assigning ownership or creating a story.
---
## Blockers
- None currently.

57
workspaces/fidelity/project-knowledge/06-daily/2026-04-30.md Normal file
View File

@@ -0,0 +1,57 @@
---
type: daily
project: fidelity
date: 2026-04-30
status: active
focus: [ao-discourse, xflow-debugging]
work-items: []
blockers: []
tags:
- daily
- fidelity
updated: 2026-05-01
---
# 2026-04-30
## Focus
- Continue the Discourse / FTTransfer AccountLink investigation and verify whether the web-view reload issue is caused by XFlow/XFlowViewMaker or by the consumer SwiftUI hierarchy.
---
## Work Done
- Compared the failing `FTTransferPlayground` path with the working non-XFlow entry point Zachary referenced.
- Explored whether XFlow event handling could be contributing to the issue, since similar event/lifecycle concerns came up in prior work.
- Ran a deeper architecture analysis of the web-view reload behavior with concrete code references.
- Identified the likely root cause as a SwiftUI view-identity / environment-republish issue around `BankInformationView` and `BankSetupWebView`, not XFlow rendering or XFlowViewMaker lifecycle logic directly.
---
## Findings
- XFlow is definitely the upstream trigger path, but the failure is driven entirely by how the consumer SwiftUI hierarchy anchors the web-view presentation.
- **Final Root Cause (Modifier-Site Teardown):** The `.ftFullScreenCover` modifier was incorrectly attached to a **volatile branch** of `BankInformationView` (e.g., inside a dynamic loaded/error state view). When the webview triggered an exit alert, the resulting state mutation caused SwiftUI to re-evaluate that volatile branch. This dismantled the presentation anchor and rebuilt it off-screen (`inWindow=false`), resulting in a blank screen.
- The working non-XFlow route survives because it uses a completely different, stronger modal/coordinator boundary (`BankSetupContainerView`), avoiding this fragile modifier placement.
- **Verified Solution:** The issue was resolved by moving the `.ftFullScreenCover` and its `shouldShowWebView` observer to the **stable root** of `BankInformationView`. By anchoring the presentation to the static root instead of a dynamic child branch, transient state changes no longer dismantle the presenter. This fixes the bug perfectly using pure SwiftUI, without any UIKit (`UIHostingController`) hacks.
---
## Communication
- David asked Zachary for the working non-XFlow entry point so the failing and working paths could be compared directly.
- David can now confidently update Jeff and Zachary that XFlow is completely cleared, and the bug was a classic SwiftUI presentation-anchor issue in the playground's consumer code.
---
## Next Steps
- Finalize the PR with the structural fix (moving the cover to the stable root of `BankInformationView`).
- Share the exact lines changed with Zachary so his team can apply this SwiftUI best practice to other covers in their playground.
---
## Blockers
- None currently.

54
workspaces/fidelity/project-knowledge/06-daily/2026-05-01.md Normal file
View File

@@ -0,0 +1,54 @@
---
type: daily
project: fidelity
date: 2026-05-01
status: active
focus: [ao-discourse, xflow-debugging]
work-items: [pdiap-16167]
blockers: []
tags:
- daily
- fidelity
updated: 2026-05-04
---
# 2026-05-01
## Focus
- Verify and document the root cause for the FTTransfer AccountLink web-view reload issue.
---
## Work Done
- Prepared the root-cause report for the FTTransfer AccountLink issue.
- Verified that XFlow eventing does not appear to be the direct cause of the reload.
- Verified that the issue persists when rolling back `XFlowSDK` to `v0.1.0`, which predates REST and modern architecture changes.
- Identified a minimal presentation-anchor change that resolves the alert auto-dismiss and web-view reload behavior.
---
## Findings
- Current evidence points to a consumer SwiftUI presentation-layer issue rather than recent XFlowSDK or XFlowViewMaker changes.
- The rollback-to-`XFlowSDK v0.1.0` finding should be included in the report because it helps separate the issue from recent XFlow changes.
---
## Communication
- Jeff asked David to put the findings into a Confluence report, share it with Zachary, and comment it on the story.
- Jeff specifically asked David to include the XFlowSDK version / rollback evidence in the report.
---
## Next Steps
- Finalize and share the root-cause report with the rollback evidence and minimal fix note.
---
## Blockers
- None currently.

51
workspaces/fidelity/project-knowledge/06-daily/2026-05-05.md Normal file
View File

@@ -0,0 +1,51 @@
---
type: daily
project: fidelity
date: 2026-05-05
updated: 2026-05-05
focus: [pdiap-15838, pdiap-16167, pdiap-15836, backlog-triage]
work-items: [PDIAP-15838, PDIAP-16167, PDIAP-15836, PDIAP-12284, PDIAP-11962, PDIAP-11961, PDIAP-11562, PDIAP-12226, PDIAP-12227, PDIAP-12228]
blockers: [consumer-validation-window, backend-rest-production-readiness, remaining-google-api-key-alerts]
tags:
- daily
- fidelity
---
# 2026-05-05
## Mattermost Evidence Promoted
- `PDIAP-16167 - AccountLink - XFlow causing web view rewrites investigation`
- Daily scrum reported minor Confluence report adjustments and planned publication.
- The Confluence report was published and the proposed Jira/Discourse/DM wording was sent to Zachary.
- Final external framing: root cause is a consumer-side SwiftUI presentation-topology / view-identity invalidation in `BankInformationView`, not XFlow or XFlowViewMaker. The issue reproduces on `XFlowSDK v0.1.0`, predating REST and Apollo-related changes, and Flagship does not appear to show the same behavior because presentation ownership is behind a more stable boundary.
- David moved `PDIAP-16167` to Done.
- `PDIAP-15838 - Remove Apollo for iOS`
- Daily scrum reported the draft PR was sent for external review.
- Bruce left minor feedback; David addressed it and pushed the suggested change.
- One review change set `responseKey: String? = nil` as the default in `FlowRESTOperationContract`, so operations such as `updateSlots`, `storeString`, and `publishEvent` can omit `responseKey` when not needed.
- David kept the file that now serves as the canonical location for XFlow domain enums after removal of GraphQL-generated code.
- Jeff directed David to move the ticket to Done, while keeping the PR unmerged for at least 30 days.
- Jeff clarified that the GraphQL-removal branch must stay up to date with `main` until REST backend is live in production with REST toggles enabled and the 30-day validation window is complete.
- `PDIAP-15836 - Modernize dismissal delegate lifecycle sequencing for pure SwiftUI environment` and `PDIAP-12284`
- Jeff initially noted that starting this work now could create a long-lived branch, because UIKit-removal work needs feature flags, consumer testing, and a later merge/release window after the REST transition finishes.
- David clarified that the spike identified and documented the root cause, but no code changes have been published yet.
- `PDIAP-12284` is the original UIKit-wrapping removal story and was reopened after rollback. David noted `PDIAP-15836` should be treated as blocked by `PDIAP-12284`, although the Jira link was not yet present.
- Jeff later asked David to start working on `PDIAP-15836` / `PDIAP-12284`, but not to move the stories to In Progress until the next sprint starts on Thursday.
- Quy had already moved the stories into the next sprint (`26Q2.6`); David will leave them in To Do until the sprint starts.
- Jeff's branch-management guidance: after implementation, maintain the branch until consumer-testing approval; merge the GraphQL-removal branch first after the REST validation period, then merge that into the `PDIAP-15836` / `PDIAP-12284` branch. Expected merge timing is roughly 90-100 days from today unless Fidelity shortens the review windows.
- Backlog triage
- Jeff asked for previously assigned backlog work because there are no other in-progress stories after `PDIAP-16167` and `PDIAP-15838` move to Done.
- `PDIAP-11962 - Closure of secret scanning alerts`: David found an October 9, 2025 email confirming submission; Matthew closed the earlier alerts/story on March 5, 2026. Two Google API Key alerts remain open and were not part of that closure.
- `PDIAP-11961 - Remediation of Exposed Secrets in XFlow iOS SDK - Request for Rotation/Invalidation`: related story for the remaining Google API Key alerts; not assigned yet. Jeff said this is not a priority yet but should be noted for future.
- `PDIAP-11562 - investigate if XFlow is being built as debug`: David identified it as related to XFlow podspec configuration and Fid4 consumption, not Sparta-team work.
- Sparta backlog notes: `PDIAP-12226` decoding is partially complete with a strict-decoding refactor still in progress; `PDIAP-12227` rendering has a working grid-layout base and is partially done; `PDIAP-12228` interactive components is blocked by unresolved mobile JavaScript execution.
## Slack Archive Backfill
- Checked the historical Slack archive for the newly recreated work-item notes.
- Promoted useful Slack backfill into the relevant work-item notes for `PDIAP-11962`, `PDIAP-11961`, `PDIAP-11562`, `PDIAP-12226`, `PDIAP-12227`, `PDIAP-12228`, and `PDIAP-12284`.
- Skipped non-Fidelity API-key hits and generic Sparta chatter that did not map cleanly to these Jira items.

19
workspaces/fidelity/project-knowledge/06-daily/2026-05-07.md Normal file
View File

@@ -0,0 +1,19 @@
---
type: daily
project: fidelity
date: 2026-05-07
updated: 2026-05-07
focus: [pdiap-15836, pdiap-12284, rest-validation]
work-items: [PDIAP-15836, PDIAP-12284]
blockers: [production-test-account]
tags:
- daily
- fidelity
---
# 2026-05-07
## Notes
- Clarified REST validation context: forcing Fid4 production endpoints by editing `initializeAppEnvironment` is related to validating REST enablement, not to the Apollo-removal story. It was a point-in-time ask that may still be useful later, but the immediate need is access to a production test account to complete validation.
- Clarified `PDIAP-15836` status: the dismissal approach David tested appears coupled to the `UIHostingController` removal path, but there may be a strategy to isolate the fix. David will investigate whether the lifecycle/dismissal fix can be applied independently.

58
workspaces/fidelity/project-knowledge/06-daily/2026-05-08.md Normal file
View File

@@ -0,0 +1,58 @@
---
type: daily
project: fidelity
date: 2026-05-08
status: active
focus: [pdiap-15836, pdiap-12284]
work-items: [PDIAP-15836, PDIAP-12284]
blockers: []
tags:
- daily
- fidelity
updated: 2026-05-08
---
# 2026-05-08
## Focus
- Capture the May 7 Mattermost thread updates for `PDIAP-15836` / `PDIAP-12284` and keep current work memory aligned with Jeff's direction.
---
## Work Done
- Mattermost sync confirmed David moved `PDIAP-15836` to In Progress and found a possible minimal dismissal fix path that would not require removing `UIHostingController`.
- Refined the Copilot implementation direction for the combined `PDIAP-15836` / `PDIAP-12284` branch: evaluate XFlowViewMaker-owned global host-mode resolution instead of Fid4-owned per-flow mapping.
- Friday standup reported `PDIAP-15836` as In Progress and aligned with `PDIAP-12284` so dismissal/lifecycle changes and UIKit-removal work can be handled in the same branch and validated together.
- Friday standup reported continued `PDIAP-12284` evaluation around a dual-path strategy: SwiftUI host should become the default while preserving the current `UIHostingController` path temporarily for validation.
---
## Findings
- David's early `PDIAP-15836` finding was that the tested dismissal approach appeared coupled to the `UIHostingController` removal path, but he was investigating whether the lifecycle/dismissal fix could be isolated.
- Current working design preference is SwiftUI host by default, including missing or unknown feature configuration; `UIHostingController` should be selected only by an explicit temporary fallback flag.
- XFlowSDK should consume a resolved host-mode decision rather than depend directly on LaunchDarkly, Flagship, or app-specific feature-flag clients.
- The SwiftUI dismissal path still needs evidence that delegate/session-clear callbacks fire only after dismissal completion; do not rely on `onDisappear` alone unless simulator logs validate it.
---
## Communication
- Jeff directed David to do the `PDIAP-15836` dismissal/lifecycle work and `PDIAP-12284` UIKit-removal work in the same branch, because both changes are disruptive enough to require consumer testing.
- Jeff approved the Friday standup wording for Teams, and David sent it.
- Jeff said he was traveling to Managua and asked David to monitor and respond on Teams while he was gone, asking for help if a message came in that David was unsure how to answer.
---
## Next Steps
- Treat `PDIAP-15836` and `PDIAP-12284` as same-branch work unless later direction changes; keep consumer-testing impact explicit.
- Ask Copilot to inspect whether XFlowViewMaker can use existing `FeatureEnabling` / `Featuring` abstractions for global host-mode resolution; if not, have it return the smallest dependency-injection option instead of pushing per-flow logic into Fid4.
---
## Blockers
- None currently.

65
workspaces/fidelity/project-knowledge/06-daily/2026-05-11.md Normal file
View File

@@ -0,0 +1,65 @@
---
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.
- 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.
---
## 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 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.
- **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.

51
workspaces/fidelity/project-knowledge/06-daily/2026-05-12.md Normal file
View File

@@ -0,0 +1,51 @@
---
type: daily
project: fidelity
date: 2026-05-12
status: active
focus: [pdiap-12284, pdiap-15836, rest-validation]
work-items: [PDIAP-12284, PDIAP-15836, PDIAP-15838]
blockers: []
tags:
- daily
- fidelity
updated: 2026-05-13
---
# 2026-05-12
## Focus
- Continue the combined `PDIAP-12284` / `PDIAP-15836` implementation path for SwiftUI host-mode routing and dismissal sequencing.
---
## Findings
- Copilot's inspection says the host-mode API appears new in the current branch and is not present on `main` in `XFlowSDK`; XFlowViewMaker's `FlowConfig` host-mode shape also differs from `main`. That makes neutral enum-case renaming safer within this branch, pending normal review.
- The current implementation keeps two host-mode enum types to preserve the module boundary: XFlowViewMaker owns host-selection policy and XFlowSDK owns presentation mechanics. Conversion is intended to stay in one place in `FlowViewBuilder` with an explicit boundary comment.
- Enum cases were renamed to neutral names: `swiftUIHost` and `uiKitHost`.
- The final feature flag key is `iOS-XflowUIKitHostEnabled`. Semantics: `true` uses the temporary UIKit host path; `false`, missing, unavailable, or unknown uses the SwiftUI host.
- Old host-flag key usage was removed rather than dual-supported because it was not found in current code search outside the branch context.
- `AnyView` was removed from `buildFlow` internals by making the builder path type-safe with `ViewBuilder`; `AnyView` remains only at the existing `FlowViewMaker` public API boundary where `makeFlowView` currently returns `AnyView`.
- 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
- 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
- No current source-level compile blocker after manual dependency/build handling. Runtime host-path validation is still pending.

53
workspaces/fidelity/project-knowledge/06-daily/2026-05-13.md Normal file
View File

@@ -0,0 +1,53 @@
---
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.
- Runtime validation for the combined `PDIAP-12284` / `PDIAP-15836` branch now looks good for AccountLink in both host modes. The SwiftUI-default path and forced UIKit-host path both showed consistent host selection and preserved dismissal sequencing, with delegate/session teardown after confirmed dismissal. No AccountLink issue was observed in either host mode during these runs.
---
## 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.
- Cleanup/review focus before push: remove temporary `XFlow-DISMISS-DEBUG` prints and consider moving new dismissal-specific helper types out of `XFlowManager.swift` into a dedicated file so `XFlowManager` keeps orchestration responsibilities while dismissal lifecycle state stays isolated.
- Follow-up SampleApp validation found a likely branch-introduced dismissal regression: SampleApp uses `initialViewController(...)` and presents a UIKit controller path, but the branch defaulted `presentationHostMode` to SwiftUI, so `endActivity` could publish to the SwiftUI dismissal subject even though no `XFlowDismissalHost` subscriber was created. The minimal fix direction is to keep `initialViewController(...)` on the UIKit host/dismiss-completion path while leaving `makeInitialFlowView(...)` on the SwiftUI host path.
- Updated SampleApp direction: SampleApp should be able to switch between UIKit-host and SwiftUI-host scenarios for validation, while XFlowSDK should infer/use the correct dismissal mechanism from the integration path rather than relying on stale/default host-mode state.
---
## Communication
- Mattermost sync refreshed May 12 context around `PDIAP-12284` / `PDIAP-15836` Jira structure, host-mode wording, and production REST-validation setup.
---
## Next Steps
- Prepare the combined `PDIAP-12284` / `PDIAP-15836` branch for push: clean temporary debug instrumentation, consider extracting dismissal helper types from `XFlowManager.swift`, run a final compile/lint or targeted validation pass, and preserve the AccountLink host-mode validation evidence for the PR/Jira update.
---
## Blockers
- None currently.

43
workspaces/fidelity/project-knowledge/06-daily/2026-05-14.md Normal file
View File

@@ -0,0 +1,43 @@
---
type: daily
project: fidelity
date: 2026-05-14
updated: 2026-05-14
focus:
- PDIAP-12284
- PDIAP-15836
work-items:
- PDIAP-12284
- PDIAP-15836
blockers: []
tags:
- daily
- fidelity
---
# 2026-05-14
## Focus
- Continue `PDIAP-12284` / `PDIAP-15836` validation and cleanup for SwiftUI-host vs UIKit-host routing and dismissal sequencing.
---
## Findings
- May 13 refreshed communication confirmed Quy said `PDIAP-12284` and `PDIAP-15836` can both remain In Progress together; no immediate Jira restructuring is required.
- SampleApp validation support was refined so the app can exercise both host scenarios explicitly: UIKit host through `initialViewController(...)` and SwiftUI host through `makeInitialFlowView(...)`.
- XFlowSDK routing should remain entrypoint-aware: the SwiftUI entrypoint prepares SwiftUI host state and clears UIKit bridge state, while the UIKit entrypoint prepares UIKit host state. This prevents `endActivity` from publishing to the SwiftUI dismissal subject when no `XFlowDismissalHost` subscriber exists.
- Follow-up SampleApp changes removed the local `AnyView` state/storage approach and moved SwiftUI-host rendering behind a `ViewBuilder`-style `flowContent` path. This keeps `AnyView` out of SampleApp and leaves type erasure only at boundaries that truly require it, such as the existing XFlowViewMaker public boundary if still needed.
- Current SampleApp host-mode validation still appears to depend on a deprecated `enable-swift-ui` toggle. Next source review should align SampleApp flag evaluation with the Fid4-style path for the specific rollback flag that enables the UIKit host, while keeping SwiftUI as the default path.
- Jeff recommended broadening Fid4 validation before opening/reviewing the PRs: test as many current Fid4 XFlow entry and dismissal points as possible in both host modes, with particular attention to AO flows.
- The next Copilot-assisted validation step should compare the previously created Confluence entry-point list against the current Fid4/XFlow/XFlowViewMaker code, identify stale or still-valid entry points, and add temporary searchable logs to confirm which entry path, host mode, and dismissal path each run uses.
## Validation To Run
- In SampleApp, validate UIKit-host mode by turning `Use SwiftUI` off, launching a flow, completing to `endActivity`, and confirming dismissal uses UIKit dismiss completion and returns to the list.
- In SampleApp, validate SwiftUI-host mode by turning `Use SwiftUI` on, launching the same flow, completing to `endActivity`, and confirming dismissal goes through `XFlowDismissalHost` lifecycle sequencing and returns to the list.
- Repeat both modes back-to-back without restarting the app to guard against stale singleton/default host-mode state.
- Re-run Fid4 AccountLink validation in default SwiftUI-host and forced UIKit-host modes after the SampleApp changes settle.
- After updating SampleApp flag evaluation, validate that the explicit UIKit-host rollback flag selects the UIKit path and that the default/missing/false value selects the SwiftUI path, matching Fid4 behavior as closely as the sample infrastructure allows.
- In Fid4, validate a broader entry/dismissal matrix in both host modes, especially AO flows, using temporary logs to confirm entry point, resolved host mode, dismissal mechanism, delegate callbacks, and session cleanup. Remove those logs before PR publication.

38
workspaces/fidelity/project-knowledge/06-daily/2026-05-18.md Normal file
View File

@@ -0,0 +1,38 @@
---
type: daily
project: fidelity
date: 2026-05-18
status: active
focus: [context-refresh, pdiap-12284]
work-items: [PDIAP-12284]
blockers: []
tags:
- daily
- fidelity
updated: 2026-05-18
---
# 2026-05-18
## Work Done
- Sent the daily scrum update for `PDIAP-12284 - Remove UIKit wrapping from XFlow`: continued SampleApp validation in both host modes, aligned the host-mode path with current flag behavior instead of the deprecated `enable-swift-ui` toggle, and started broader Fid4 smoke testing with temporary validation logs.
## Findings
- While refreshing context for Adam's duplicate-request question, David clarified that the April 4 follow-up in the `Production - Crypto Delinking issue` thread was from David/Jeff's side after Yuva's March 30 comment.
- That April 4 follow-up said the iOS SDK-side network requests looked correct and intentional, matched Android, and did not reproduce duplicate `open-account` API calls from the client side in non-prod.
- Therefore, prior `PDSPS-29371` context should not be summarized as a confirmed reproduction from the iOS SDK side; it is related background, but the previous investigation did not reproduce the issue from the client-side SDK path.
- Follow-up Copilot analysis suggested a plausible but unconfirmed link between REST migration and the current duplicate-page/account report: REST did not introduce a new duplicate-trigger mechanism by itself, but the REST/FTNetwork path may have changed timeout/error behavior enough to expose an existing XFlow re-trigger path under slow BPDC responses.
- Treat that REST link as a hypothesis requiring current logs, dates, versions, and timeout/error evidence before reporting it as root cause.
- Jeff asked whether the REST switch could have impacted Adam's duplicate-page/account report, while noting he assumed they were unrelated. David initially answered that REST should only affect XFlow API transport, not page sequencing or submission count, and offered to trace REST-toggle state once Adam provided an exact date and flow/page.
- After Adam provided more context, David updated Jeff that REST still should not be treated as a direct sequencing cause, but it cannot be fully ruled out because REST/FTNetwork timeout/error behavior might expose an existing XFlow retry or page-rebuild path under load.
- Jeff asked for either a proposed response to Adam or a statement that more information is needed, suggesting Adam should open a Discourse ticket and attach the relevant evidence if more detail is required.
---
## Next Steps
- Frame any update to Jeff as a context refresh: related prior investigation exists, but the previous iOS SDK-side review did not reproduce duplicate client-side `open-account` calls, so current logs/examples are needed before calling the new report the same issue or a regression.
- If discussing REST impact, separate confirmed facts from hypothesis: confirmed prior non-prod iOS review did not reproduce duplicate client-side calls; current hypothesis is that REST timeout/error semantics may expose the existing XFlow model-state retry/rebuild path under production load.
- Prepare a concise proposed response to Adam that asks for a Discourse ticket with exact incident date/time, affected flow/page, app/XFlowSDK version, REST state if known, user journey logs, and examples needed to compare against `PDSPS-29371` / `PDIAP-11561`.

21
workspaces/fidelity/project-knowledge/06-daily/2026-05-19.md Normal file
View File

@@ -0,0 +1,21 @@
---
type: daily
project: fidelity
date: 2026-05-19
status: active
focus: [pdiap-12284, duplicate-ao-report]
work-items: [PDIAP-12284]
blockers: []
tags:
- daily
- fidelity
updated: 2026-05-19
---
# 2026-05-19
## Work Done
- Sent the daily scrum update for today.
- Proposed and sent the request for a Discourse ticket to Adam to obtain details (exact date/time, affected flow/page, build version, logs, and examples) for the duplicate account-opening report.
- Confirmed that no new Discourse ticket with the `xflog` tag has been posted yet.

29
workspaces/fidelity/project-knowledge/06-daily/2026-05-20.md Normal file
View File

@@ -0,0 +1,29 @@
---
type: daily
project: fidelity
date: 2026-05-20
status: active
focus: [pdiap-12284, pdiap-15836, duplicate-ao-report]
work-items: [PDIAP-12284, PDIAP-15836]
blockers: [duplicate-ao-report-waiting-on-adam-discourse-details]
tags:
- daily
- fidelity
updated: 2026-05-20
---
# 2026-05-20
## Work Planned / Current State
- Continue `PDIAP-12284` / `PDIAP-15836` validation across current Fid4 XFlow entry points and dismissal paths.
- Current validation evidence from sessions `004` and `005` shows SwiftUI-host load/dismiss/delegate-cleanup coverage for `HybridBrokerageAccountOpening` and `accountlink`; `HybridYouthAccountOpening` has load/start coverage only and still needs complete dismissal coverage.
- Remaining validation gaps include AO deep-link coverage, Fid4 surface attribution for launch wrappers, common-launch flows, `HybridBloomAccountOpening`, and explicit UIKit-host mode validation.
- Plan to open a draft PR today for the combined `PDIAP-12284` / `PDIAP-15836` branch while validation continues.
## Work Done
- Opened draft PRs for XFlowSDK and XFlowViewMaker for the combined PDIAP-12284 / PDIAP-15836 branch.
- Shared the draft PRs with the team on Teams to begin the review process.
- Monitored Discourse for Adam's details on the duplicate account-opening issue, which is still pending.

31
workspaces/fidelity/project-knowledge/06-daily/2026-05-21.md Normal file
View File

@@ -0,0 +1,31 @@
---
type: daily
project: fidelity
date: 2026-05-21
updated: 2026-05-21
focus:
- PDIAP-12284
- PDIAP-15836
work-items:
- PDIAP-12284
- PDIAP-15836
blockers: []
tags:
- daily
- fidelity
---
# 2026-05-21
## Findings
- Screenshot evidence from the XFlow entry-point validation checklist indicates `HybridBloomAccountOpening` has both UIKit-host and SwiftUI-host validation marked complete, with full dismissal/cleanup confirmed for both host modes.
- `HybridBrokerageAccountOpening` and `HybridYouthAccountOpening` are also marked as validated for SwiftUI host, UIKit host, and full lifecycle/dismissal coverage in the checklist.
- The `accountLink` P2P transfer flow is marked validated for SwiftUI host and dismissal on SwiftUI host, but UIKit-host validation is still pending; the checklist notes Fid4 surface attribution is unclear and may go through `XFlowCommonLaunchView` or direct FTTransfer builder.
- `ADDeepLinkLaunchView` remains untested in the checklist for native-on, native-off, and dismissal paths.
## Validation To Run
- Complete UIKit-host validation for `accountLink` / P2P transfer flow.
- Validate `ADDeepLinkLaunchView` for both native toggle branches and dismissal behavior.
- Keep using the checklist as a general entry-point guide rather than a session-by-session log.

49
workspaces/fidelity/project-knowledge/06-daily/index.md Normal file
View File

@@ -0,0 +1,49 @@
---
type: daily-index
project: fidelity
updated: 2026-05-08
tags:
- daily
- map
---
# Logs Index
Daily logs capture evolving evidence and same-day work context.
Promote durable facts into `workspaces/fidelity/project-knowledge/01-current/`, `workspaces/fidelity/project-knowledge/02-work-items/`, or `workspaces/fidelity/project-knowledge/03-context/` when they should survive beyond the day.
---
## Logs
- [2026-04-08](2026-04-08.md)
- [2026-04-09](2026-04-09.md)
- [2026-04-10](2026-04-10.md)
- [2026-04-13](2026-04-13.md)
- [2026-04-14](2026-04-14.md)
- [2026-04-15](2026-04-15.md)
- [2026-04-16](2026-04-16.md)
- [2026-04-20](2026-04-20.md)
- [2026-04-21](2026-04-21.md)
- [2026-04-27](2026-04-27.md)
- [2026-04-28](2026-04-28.md)
- [2026-04-29](2026-04-29.md)
- [2026-04-30](2026-04-30.md)
- [2026-05-05](2026-05-05.md)
- [2026-05-07](2026-05-07.md)
- [2026-05-08](2026-05-08.md)
- [2026-05-11](2026-05-11.md)
- [2026-05-12](2026-05-12.md)
- [2026-05-13](2026-05-13.md)
- [2026-05-14](2026-05-14.md)
- [2026-05-18](2026-05-18.md)
- [2026-05-19](2026-05-19.md)
---
## Related Memory
- [Current Work](../01-current/current-work.md)
- [Work Item State](../01-current/work-items.md)
- [Work Item Index](../02-work-items/index.md)
- [Context Index](../03-context/index.md)