103 lines
9.9 KiB
Markdown
103 lines
9.9 KiB
Markdown
---
|
|
type: current
|
|
project: fidelity
|
|
status: active
|
|
updated: 2026-04-17
|
|
tags:
|
|
- current-work
|
|
- fidelity
|
|
---
|
|
# Current Work
|
|
|
|
## Focus
|
|
|
|
- Keep Fidelity context current from daily work performed on another machine
|
|
- Track REST migration findings
|
|
- Debug Discourse and AO issues
|
|
- Prepare better updates for the current manager or stakeholder through Mattermost
|
|
- Follow up on active tickets through `project-knowledge/02-work-items/`, especially `PDIAP-15838` and `PDIAP-15836`
|
|
- `PDIAP-15765` is done and `PDIAP-14859` is also done
|
|
- `PDIAP-15838` is assigned to the next sprint
|
|
- Do not describe `PDIAP-15838` as current-sprint in-progress implementation work
|
|
- `PDIAP-15836` comes after the current REST-investigation / Apollo-removal work
|
|
- Keep the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` scenario out of `PDIAP-15765` scope unless later evidence proves it belongs there
|
|
- Include feature-flag planning for the broader UIKit-removal spike, including dismissal sequencing changes that affect consumers
|
|
- Thoroughly verify current `ApexBridgingAddressComponent` / rule-loading usage before describing it as inactive or dead code
|
|
- Reconcile the old UIKit address-rule path with the current SwiftUI handling path through the adapter/view-model layer before reporting final ownership or replacement guidance
|
|
- The ApexKitV3 risk write-up for Quy has been published and sent; use that research as the current high-level framing for dependency-removal risk
|
|
- Investigate the current XFlow dependency surface on `ApexKitV3`, including the `23` build errors on removal and the remaining `13` errors when swapping to `ApexKitSwiftUI`
|
|
- The process-oriented rollout document for the UIKit-removal spike is approved and ready to publish for spike closure
|
|
- The rollout 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 rollout document uses a global feature-flag rollout model with broad XQ1 validation before production enablement
|
|
- The rollout document should use the new flag name `xflow-swiftui-container-enabled` and note that the flag will be added later during implementation
|
|
- Re-check the authenticated AO validation issue with scenario-specific evidence: the `HybridYouthAccountOpening` / `TeenIdentityCheck` path currently points to an iOS-only decoding gap, while a separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` case reproduces on both platforms
|
|
- The immediate Youth issue was fixed on the service side for the Youth-flow `TeenIdentityCheck` path after the payload moved from `birthDate` to `validations`; local Fid4 validation also confirmed it. The XFlowSDK-side fallback PR should still ship in the next release
|
|
- Jeff later decided the iOS fallback PR should be treated as the primary fix path for the Youth issue rather than relying on a separate service rollout; the QA-side service change has since been rolled back and Fid4 validation still passed with the PR in place
|
|
- When describing the XFlowSDK fallback PR, frame it as a compatibility improvement for similar future `birthDate` payloads, not as a fix for the separate `HybridBrokerageAccountOpening` / `JointIdentityCheck` issue
|
|
- The Youth / `TeenIdentityCheck` issue was iOS-only; do not describe it as reproducing on both platforms
|
|
- The service-side payload update and the XFlowSDK fallback PR address the same Youth / `TeenIdentityCheck` issue; do not split them into separate Youth issues when summarizing scope
|
|
- The `PDIAP-15765` compatibility fix is now fully closed out and the story is in Done
|
|
- A new urgent consumer report says REST calls fail on iOS when the toggle is enabled, but current local validation says REST works on both `main` and `release/4.30`; treat version/flag mismatch as the leading explanation until broader evidence says otherwise
|
|
- David has now confirmed the production build already contains the commit that added the LaunchDarkly flag, so the current investigation should focus more on LaunchDarkly evaluation context, targeting, initialization timing, and any additional transport-selection gating on iOS
|
|
- Jeff explicitly wants the REST-flag investigation to stay ahead of Adam's separate service-side flow report for now and wants faster visible progress on that path
|
|
- Jeff suggested broadening the investigation support path while direct Flagship LaunchDarkly access is still missing: monitor the Tauf thread, follow up with Jeffrey O'Leary, package the scenario for the AI tool with build settings and tool details, and ask Aylwing for a quick perspective if available
|
|
- The Fidelity-side AI tool Jeff referenced for this investigation is GitHub Copilot
|
|
- Jeff later relayed that Adam says the latest build is now activating REST correctly, so David should switch back to the current Jira story work for removing GraphQL and related LaunchDarkly toggles
|
|
- Before closing out the AO thread, send one more working-group Teams reply that summarizes the original iOS issue, links the Jira comment, Discourse comment, and PR, and separates the remaining `HybridBrokerageAccountOpening` / `JointIdentityCheck` service-side issue
|
|
- The `HybridBrokerageAccountOpening` / `JointIdentityCheck` rule-content issue appears unchanged between QA and Production in Cogstore and should be treated as the remaining service-side follow-up
|
|
|
|
---
|
|
|
|
## Active Concerns
|
|
|
|
- Authenticated vs non-authenticated behavior
|
|
- Reproducibility across entry points
|
|
- Backend-driven inconsistencies in XFlow
|
|
- Distinguishing external issues from true regressions
|
|
- Preserving accurate context when summarizing work from another machine
|
|
- Validating dismissal sequencing changes across SwiftUI flows
|
|
- Keeping REST deprecation scope explicit while GraphQL fallback still exists
|
|
- Current LaunchDarkly access does not include Flagship LD projects; only the sample app LD project is available from David's side
|
|
- David does not yet know where the iOS app assembles or identifies the LaunchDarkly context attributes, but can inspect source code and use Charles Proxy during investigation
|
|
- Current local evidence shows the LaunchDarkly boolean evaluating to `true`, with payload and context present from the iOS side, so the remaining uncertainty is around production-side context interpretation, timing, caching, or additional downstream gating
|
|
- The urgent REST-activation investigation is no longer the immediate blocker after Adam reported the latest build working, but the earlier context/timing uncertainty remains useful background if the issue reappears
|
|
- Adam reported the earlier REST activation problem, and he or his team validate behavior on real devices rather than simulator-only paths
|
|
- Avoid treating GitHub Copilot or LaunchDarkly as story-specific tools; both are broader Fidelity workflow tools that happened to matter in this investigation
|
|
- Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
|
|
- Keep the Apollo-removal / REST-migration context ready for the next sprint, when `PDIAP-15838` becomes active
|
|
- Avoiding assumptions when comparing iOS and Android validation behavior; scenario-specific parity needs to be confirmed before reporting scope
|
|
- Avoiding assumptions about legacy Apex/ApexKit paths; breakpoint evidence and helper usage both need to be reconciled before reporting ownership or replacement guidance
|
|
- When ownership is still uncertain under production pressure, prefer rollback-plus-investigation framing over confident blame assignment to consumers
|
|
- Swift 6 migration risk is now time-sensitive because external dependency removal could break XFlow before the planned `26Q3` work
|
|
- The write-up for Quy should remain the reference framing for moderate effort, medium risk, and required consumer validation while deeper implementation details are still being researched
|
|
|
|
---
|
|
|
|
## Communication Priorities
|
|
|
|
- Standups should reflect the latest technical state, not generic progress
|
|
- Standups should prefer updates directly tied to active work items over one-off memory refreshes or side questions
|
|
- Standups should include story titles whenever a reported update maps to a Jira item
|
|
- Standups should use bullet points for each item, but avoid dash-separated title formatting inside the sentence body
|
|
- When one Jira item has multiple concrete updates, prefer one top-level Jira bullet with indented sub-bullets rather than repeating the same Jira line multiple times
|
|
- When pairing a Jira ID with a title in standups, prefer a simple hyphen after the ID or omit punctuation instead of using commas
|
|
- For Friday standups that may also be sent to Teams, prefer plain language over internal implementation terms; avoid words like `fallback` unless the meaning is obvious to the audience
|
|
- When a release item is waiting on approvals or pipeline work, make the parallel story work explicit instead of making the update sound blocked on waiting alone
|
|
- Standups should omit side questions or manager-only context refreshes unless they materially changed story work
|
|
- If a root cause document or other documentation update directly supports a story, it should be reported under that story instead of as a separate standalone item
|
|
- Standups should omit items not tied to a story unless they are real blockers
|
|
- If a new request is important work but not directly tied to a Jira item, include it as a standalone bullet instead of forcing it under a story
|
|
- Manager updates should be short, precise, and natural in English
|
|
- Mattermost messages should make scope and next action explicit
|
|
- When root cause is not fully isolated, do not position framework conclusions as authoritative consumer-side fault
|
|
- Standups should be written as David's external progress report and should not mention Jeff by name
|
|
- Standups should never mention Mattermost because it is internal-only communication
|
|
|
|
---
|
|
|
|
## Notes
|
|
|
|
- REST remains behind a feature flag
|
|
- Validate against main before calling something a regression
|
|
- This workspace is the context source for communication, not the source of product code changes
|