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 carrying the already-published XFlowViewMaker update through the Fid4 PR and downstream consumer path
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 XFlowViewMaker follow-up has also been approved, published, and unblocked in Fid4 through a podspec-repo change, and the current downstream step is the open Fid4 PR/update path
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
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
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
