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

Add project-knowledge structure and templates

Browse Source 
- Introduced new maps for navigating project knowledge, including "Current Work," "Fidelity Domain," "Fidelity Apps," "Work Items," and "People."
- Created base files for daily notes, decisions, people, systems, work items, and workstreams with defined properties and views.
- Developed templates for daily notes, decisions, meeting notes, persons, systems, work items, and workstreams to standardize documentation.
- Updated scripts and prompts to reflect the new project-knowledge directory structure.
- Removed outdated onboarding and start-here documents, consolidating relevant information into the new maps.
- Ensured all references in workflows and scripts point to the new project-knowledge paths.
This commit is contained in:
David Delagneau
2026-04-17 15:52:08 -06:00
parent 11fdb17fcb
commit dbc1894e27
175 changed files with 1163 additions and 914 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

97
project-knowledge/06-daily/2026-04-17.md Normal file
View File

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

34
project-knowledge/06-daily/index.md Normal file
View File

@@ -0,0 +1,34 @@
---
type: daily-index
project: fidelity
updated: 2026-04-16
tags:
- daily
- map
---
# Logs Index
Daily logs capture evolving evidence and same-day work context.
Promote durable facts into `project-knowledge/01-current/`, `project-knowledge/02-work-items/`, or `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)
---
## 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)