fidelity-ai-workspace/workspaces/fidelity/project-knowledge/06-daily/2026-04-10.md

type, project, date, focus, work-items, blockers, updated, tags

type	project	date	focus	work-items	blockers	updated	tags
daily	fidelity	2026-04-10	xflow-swiftui-migration rest-migration ao-discourse	pdiap-14859 pdiap-15765 pdiap-15836 pdiap-15838		2026-04-16	daily fidelity

2026-04-10

Clarification

• PDIAP-15838 should not be framed as directly tied to the UIKit-removal spike.
• Avoid wording that implies PDIAP-15838 is dependent on or part of the dismissal-sequencing / UIKit-removal spike.
• Standups should prioritize updates directly tied to active work items and omit side questions such as version reminders that were only for internal context.
• Current focus for today is to finalize PDIAP-14859 with a dual UIKit/SwiftUI plan that removes UIHostingController dynamically while preserving both flows appropriately.
• Omit standup items that are not directly related to a story.
• Use the approved title Remove Apollo for iOS for PDIAP-15838.
• When a documentation or root cause update directly supports a story, report it under that story instead of as a separate standup item.
• In standups, format Jira references as ID - Title or ID Title, not ID, Title.
• Jeff clarified that PDIAP-15838 is the next story to work on and PDIAP-15836 comes later.
• Clarification: the feature-flag and rollout planning feedback applies to the broader UIKit-removal spike, not only to the dismissal sequencing changes; the sequencing work should fit into that same consumer rollout plan.
• Current priority is to create a process-oriented document that explains the rollout plan Jeff described for the UIKit-removal spike, with the goal of sharing it for feedback.
• Clarification: the 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 dismissal sequencing work is only one part of that broader migration plan.
• The document should clearly explain that the rollout uses a dual-path pattern to switch between the UIHostingController path and the SwiftUI-only path during migration.
• Jeff said the remaining spike deliverable is a clear consumer-facing rollout plan covering risky entry points like FTTransfer, consumer communication, XQ1 validation, a 30-day production period with no reported bugs, and a follow-up release to remove the feature flag and old code; he suggested sending that process-oriented document to Quy for feedback when ready.
• Reviewed the first Copilot-generated draft of the SwiftUI-only migration rollout document from screenshots.
• The draft already includes the main requested elements: dual-path rollout, xflow-master-swiftui-enabled, XQ1 validation, FTTransfer coordination, rollback handling, 30-day stabilization window, and final cleanup release.
• The next revision should shift the tone slightly away from formal incident/operations language and make the consumer rollout sequence, decision owners, and entry-point-based enablement flow feel more like an engineering migration plan than a generic release runbook.
• Correction for the next rollout-document revision: the rollout should not be framed as entry-point-based enablement; it uses a global feature flag and should emphasize broad XQ1 validation before any production release.
• Correction for audience framing: the document is consumer-facing and should avoid stakeholder-oriented wording.
• Further correction for the rollout document: it should not say production rollout begins with lower-risk consumers. The production flag is global and applies across flows together once the team decides to enable it.
• The document should present broad XQ1 validation as the required gate before any production rollout, not as one stage within a consumer-by-consumer enablement sequence.
• The migration framing should also call out that the rollout incorporates architectural improvements learned from prior SwiftUI iterations, especially where earlier approaches introduced SwiftUI anti-patterns.
• Reviewed the next screenshot-based revision of the rollout document. It now correctly reflects a global production flag model, broad XQ1 validation before production enablement, consumer-facing wording, and architectural improvements learned from prior SwiftUI iterations.
• Remaining polish areas in the latest draft: reduce lingering operational/runbook wording (SLA, operational response, release manager delegate, heavy monitoring-threshold language) and make the high-risk-consumer section sound more like coordination/validation within a global rollout than a separate rollout phase.
• The rollout document should be more concise and should not use an overly complex multi-phase model.
• Reviewed the newer simplified screenshot-based revision. The rollout structure is now much closer to the intended model: a simple gated flow of broad XQ1 validation, global production enablement, then a 30-day stabilization window before cleanup.
• Remaining issues in the latest draft are mostly wording and trimming: it still includes extra runbook-style sections such as Production Monitoring and Guardrails, Coordination Model for High-Risk Consumers, Rollback and Operational Response, and Decision Gates Summary, which may be more detail than needed for the concise consumer-facing version.
• Reviewed another screenshot-based revision after the simplification prompt. The top-level rollout flow is still good and concise, but the lower half of the document still retains most of the extra runbook-style sections, so the latest revision did not yet materially reduce those details.
• Clarified the AO/Discourse config explanation for the authenticated TeenIdentityCheck DOB issue: the requirement is not to rename the root from birthDate to validations; instead, the validation-rules payload should contain a JSON object whose root key is validations, and if the age gate is required it should include eighteenOrAbove: true, matching the CheckIdentity structure rather than relying on a separate transactional rule boolean like "eighteen-or-above": true.
• Further clarification for the same AO/Discourse thread: the reply should explicitly state that the earlier comment was referring to the literal "eighteen-or-above": true attribute inside the transactional-rules array, while still distinguishing that from the separate validation-rules structure.
• Additional clarification for the authenticated TeenIdentityCheck config issue: the validation-rules attribute is the structure that drives the check. CheckIdentity was already configured correctly. The TeenIdentityCheck problem had two parts: the wrong root key (birthDate instead of the expected validations) and the missing eighteenOrAbove attribute inside validation-rules.
• For the Rashmi reply, the intended closing clarification is that the previous CheckIdentity validation-rules shape is the expected model for TeenIdentityCheck, and a JSON snippet can be shared to show the expected structure directly.