90 lines
8.0 KiB
Markdown
90 lines
8.0 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 `vault/02-work-items/`, especially `PDIAP-14859`, `PDIAP-15765`, `PDIAP-15836`, and `PDIAP-15838`
|
|
- Wrap up `PDIAP-14859` by publishing the approved rollout document, linking the spike-result documents and follow-up story, then closing the spike
|
|
- After the immediate `PDIAP-14859` closeout and `PDIAP-15765` resume work, return to `PDIAP-15838`; `PDIAP-15836` comes later
|
|
- Finish `PDIAP-15765` propagation after the XFlow `2.8.48` release by getting the remaining FTFrameworks code-owner approval on the XFlowViewMaker PR, then run the pipeline and update Fid4 while continuing `PDIAP-15838` in parallel where possible
|
|
- 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 merged and released in XFlow `2.8.48`; the remaining near-term work is getting the last FTFrameworks code-owner approval on the XFlowViewMaker PR, then running the pipeline and updating Fid4
|
|
- 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
|
|
- Defining a consumer rollout plan for UIKit-removal sequencing changes, including validation, communication, and feature-flag retirement
|
|
- Closing `PDIAP-14859` cleanly with the right links, blocker relationship, and feature-flag wording
|
|
- 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
|