fidelity-ai-workspace/ai/state/current.md

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 ai/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
• Resume PDIAP-15765 for the authenticated iOS-only HybridYouthAccountOpening / TeenIdentityCheck handling gap so iOS aligns with Android behavior
• 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 appears fixed on the service side after the payload moved from birthDate to validations, but the XFlowSDK-side fallback PR should still ship in the next release

---

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
• 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