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

feat: Update rollout documents and work items for UIKit-removal spike, clarifying consumer communication and validation expectations

Browse Source
This commit is contained in:
David Delagneau
2026-04-14 14:14:33 -06:00
parent bbac484170
commit 494978605e
5 changed files with 64 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
ai/work-items/pdiap-14859.md
View File

@@ -19,7 +19,7 @@
- Define a consumer-facing rollout plan for the broader UIKit-removal work.
- Preserve both UIKit and SwiftUI paths appropriately while introducing the new path safely.
- Cover risky entry points such as `FTTransfer`.
- Cover risky entry points such as `FTTransfer`, while keeping the latest spike finding explicit that consumer-side changes there may no longer be strictly required after the SwiftUI dismissal behavior is applied correctly.
- Include validation expectations in `XQ1`.
- Use a global feature-flag rollout model rather than entry-point-based enablement.
- Include consumer communication expectations.
@@ -33,7 +33,9 @@
- The feature-flag and rollout planning guidance applies to the broader UIKit-removal spike, not only to dismissal-sequencing work.
- Jeff suggested sending the process-oriented rollout document to Quy for feedback when ready.
- The draft shared with Jeff already reflects the global feature flag, broad `XQ1` validation, and consumer-facing rollout flow guidance.
- Await Jeff's review feedback before treating the rollout framing as final.
- Additional review feedback from April 13: rename the proposed flag to `xflow-swiftui-enabled`, make consumer contact and `XQ1` validation explicit in the first phase, remove overly technical rollout wording, and avoid implying there are no consumer-side changes without qualification.
- On April 14, Jeff asked whether the FTTransfer part of the rollout document also needed updating; David confirmed the document had already been revised to clarify that root-cause section.
- Await final follow-up after incorporating the latest review feedback.
---

7
ai/work-items/pdiap-15765.md
View File

@@ -20,12 +20,17 @@
- Root cause was documented.
- The original external report was incomplete.
- For the config discussion, `CheckIdentity` was already correct. The `TeenIdentityCheck` issue had two config gaps inside `validation-rules`: the root key should be `validations`, and the age gate also needs `eighteenOrAbove` there when that rule is required.
- Follow-up validation on April 13 showed two distinct authenticated scenarios rather than one uniform cross-platform issue.
- A `HybridBrokerage` scenario reproduces on both iOS and Android.
- A Youth-flow `TeenIdentityCheck` scenario works on Android but fails on iOS.
- Current evidence suggests Android is more flexible in how it decodes rule variations, while iOS is stricter about the expected `validation-rules` structure.
---
## Current Guidance
- Treat the issue as scoped and understood unless new evidence appears.
- Treat the iOS-only Youth-flow discrepancy as the main client-side issue currently aligned with the story.
- Keep the cross-platform `HybridBrokerage` scenario separate until it is clear whether it is a service/config issue, a distinct bug, or an unreported rule-processing difference.
- Keep the authenticated-user qualifier whenever this ticket is mentioned.
- Do not describe it as a generic validation issue without the `TeenIdentityCheck` and auth context.